WPF MVVM Introduction

Today writing large WPF application is very complex task. WPF application composed of many
complex UI designs, larget set of business objects, data storage objects and presentation logic
which makes the development of WPF application quite cumbersome.

Microsoft introduced a new pattern "MVVM" to make the development of WPF application
easier.

MVVM is an architectural pattern which separates the development of GUI interface with
business logic, back-end logic and presentation logic.

MVVM pattern composed of three parts:

1. Model
2. View
3. ViewModel

Model
Model is the implementation of the application domain's model and it's contains business objects,
validations, and back-end objects to retrieve and saving the data.

View
View is the user interface of WPF application developed in XAML markup language. It consists
of multiple controls like Window, Usercontrols, Buttons, Labels etc. It also includes resources
like ControlTemplate, DataTemplate, and Styles.

View should not contain any code in the code-behind file.

ViewModel
 ViewModel is the mediator between the View and Model. It is responsible for handling
the Presentation Logic and retrieve/saving the data from the Model.
 ViewModel interacts with the Model by invoking public methods in the Model classes. It
gets the data from the Model and send the data to the View.
 View interacts with the ViewModel by using the data-binding and command features of
WPF. ViewModel provides the implementation of commands that executes when user
interacts with the view.
 ViewModel should be designed as loosley coupled. ViewModel does not contain a
reference to the View. It does not know any existence of the View.

1
Advantages of MVVM
1. Lossley coupled architecture : MVVM makes your application architecture as loosley
coupled. You can change one layer without affecting the other layers.
2. Extensible code : You can extends View, ViewModel and the Model layer separately
without affecting the other layers.
3. Testable code : You can write unit test cases for both ViewModel and Model layer
without referencing the View. This makes the unit test cases easy to write.

More about. http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx

OTHER PATTERNS
MV(C-P-VM) Most of beaver is also over all same.

 Model: Data, entity, ORM.

 View: Presentation Layer, User Interface.

 Presenter or Controller or ViewModel: Business Object, Business Layer.

Model View controller (MVC)

Model View Presenter (MVP)
Model View View-Model (MVVM)

These are all Design Patterns with the same goals but differing solutions.

The strengths of these Design Patterns are:

 Rich UI

2
  Testability
 Modularity
 Maintainability
 Flexibility

Model View Controller (MVC)

 First described in 1979 for Smalltalk at Xerox PARC

 The Controller is the centerpiece that decouples the Model and View.
 User interaction event
 The Controller handles events and converts them to a user action that the Model can understand
 The Model manages the behavior and data of the application domain
 The View interacts with the Controller and the Model to generate a user interface

More about MVC: http://msdn.microsoft.com/en-us/library/dd394709(v=vs.90).aspx

Model-View-Presenter (MVP)

 MVP originated in early 1990s

 MVP is a derivative of MVC
 Two types of implementation
 ive View
 Supervising Controller
 Presenter assumes the functionality of the MVC Controller
 The View is responsible for handling UI events
 The Model becomes strictly a Domain Model
 It is more User Interface centric

More about MVP: http://msdn.microsoft.com/en-us/library/ff647543.aspx

3
MVVM Architecture

In the above It’s shown the Model-View-ViewModel architecture, .The ViewModel sends a notification to
the view. Unit testing is connected to the ViewModel. See in this diagram the ViewModel is the "Glue"
connected to the view as well as the model and the unit test class also. The ViewModel is aware of all the
properties of the method of the Model and it is also aware of the needs of the View.

4
View in MVVM

The View is the client interface, input-output interface or the user interface. It collects all the user interface
elements of the window, navigation page, user control, resource file, style and themes, custom tools and
controls. The view is unaware of the ViewModel and the Model, and vice versa the ViewModel and Model
is unaware of the View and control is tightly decoupled.

But the view model is aware of the needs of the view. They communicate by data binding and a
dependency property or properties.

Communication between the view and view model occurs by the DataContext property. Code behind the
view only contains a constructor that calls an InitializeComponent method and in some cases people use a
UI logic event here, visual and logical tree code implementation and custom logic property. But that's not
good in the MVVM Design Pattern, because we create unit testing on the ViewModel and a parameter
through the view model. In this case the view code behind logic and data will not be tested and you need
to again test the code behind page. One view can only communicate with a single view-model at a time.

5
ViewModel in MVVM

ViewModel is a non-visual class. The MVVM Design Pattern does not derive from any WPF or Silverlight
based class. The ViewModel is unaware of the view directly. Communication between the View and
ViewModel is through some property and binding. Models are connected directly to the ViewModel and
invoke a method by the model class, it knows what the model has, like properties, methods and also is
aware of what the view needs.

One View-Model can connect to multiple models, work like a one-to-many relationship and encapsulate
business logic and data for the View. A ViewModel inherits some interface like INotifyPropertyChanged,
Icommand INotifyCollectionChanged.

Model in MVVM

The Model represents your data, like employee, product or customer. Generally define a set of properties
and methods. You might create a model from scratch or get it from an ORM like Entity Framework or
from some server proxy. The Model is responsible for managing the application data and for ensuring its
consistency and validity by encapsulating the required business logic and data validation. Accessing a
model instance by querying a database and create an instance in a loop or using WCF, or REST.

Depending on your business requirements, call a method to retrieve a single or a collection of instances.
The Model classes typically provide data validation and error reporting through either the IDataErrorInfo
or INotifyDataErrorInfo interfaces.