MVVM (Model-View-ViewModel)

The Model View ViewModel (MVVM) is an architectural pattern used in software engineering.

It originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.

Largely based on the Model-view-controller pattern (MVC), MVVM is targeted at modern UI development platforms.

MVVM was designed to make use of specific functions in WPF to better facilitate.

The separation of View layer development from the rest of the pattern by removing virtually all “code behind” from the View layer.

Instead of requiring Interactive Designers to write View code, they can use the native WPF markup language XAML and create bindings to the ViewModel, which is written and maintained by application developers.

This separation of roles allows Interactive Designers to focus on UI needs rather than programming or business logic, allowing for the layers of an application to be developed in multiple work streams.

 

Model

1. The Model represents the actual data and/or information we are dealing with.An example of a model might be a contact (containing name, phone number, address, etc.) or it can be the Web service , Data Access in short anything which provide the data.
2. The key to remember with the model is that it holds the information.

 

ViewModel

1. ViewModel is the base in the MVVP pattern.Acts as a “View” specific model class,adapting your model to the need of the view.
2. It hold the state of the view.but do not know or hold the reference of the view.View is responsible for hold the reference of the ViewModel. 
3. Responsible for talking with model/Service through their interfaces.
4. The viewmodel may expose the model directly, or properties related to the model, for data-binding
5. The ViewModel can also Validate the Data.
6. The viewmodel exposes not only models, but also exposes Notifiable Properties, and Observable Collections to the View.The View Binds to these ViewModel entities/members(supported by wpf).

View

1.  The view is what most of us are familiar with and the only thing the end user really interacts with. It is the presentation of the data.
2. The View holds a reference to the ViewModel.View is completely isolated from the model.
3. In MVVM ,A View is defined in XAML and should not have any logic in the code-behind. It binds to the view-model by only using data binding.
4. The view handles its own UI events, then maps them to the viewmodel via commands.

General

1. The view and the viewmodel communicate via data-binding, method calls, properties, events, and messages.
2. The models and properties on the viewmodel are updated from the view via two-way databinding.
3. When user update the view,Databinding pushes changes to the ViewModel.
4. when Model updates ViewModel DataBinding pushes changes to the View. 
5. The key thing to remember is that you have one and only one ViewModel per view.

Implementations of the MVVM pattern have the following characteristics:

1. The View class generates events in response to user interactions, and these events are handled by the corresponding ViewModel class. The View class has no knowledge of how the events are handled, or what impact the events will have on the Model.
2. The ViewModel class determines whether a user action requires modification of the data in the Model, and acts on the Model if required. For example, if a user presses a button to update the inventory quantity for a part, the View simply notifies the ViewModel that this event occurred. The ViewModel retrieves the new inventory amount from the View and updates the Model. This decouples the View from the Model, and consolidates the business logic into the ViewModel and the Model where it can be tested.
3. The Model notifies the ViewModel if the data in the underlying data store has changed. Generally, when you work with a stateless request/response model, you don’t need to worry about whether data has changed while the request is being processed, since the window of time is small. With rich Internet application (RIA) approaches, the Model data typically stays in memory for longer, and multiple active Views may share the Model data. A user may make changes in one View that affects a different View within the application. The Model fires events to notify any active ViewModels of data changes.
4. The ViewModel notifies the View when information has changed. This is typically automated through the two-way binding infrastructure described previously.

Benefits and Consequences of Using MVVM

The benefits of MVVM are the following:

1. Loose Coupling.
2. A ViewModel provides a single store for presentation policy and state, thus improving the reusability of the Model (by decoupling it from the Views) and the replaceability of the Views (by removing specific presentation policy from them)
3. The Model-View-ViewModel design improves the overall testability of the application. One can easily create unit tests that target the Model and the ViewModel layers. The MVVM design also improves the “mockability” of the application, by allowing easy run-time simulation of the tiers, which is crucial to testing complex software products.
4. The Model-View-ViewModel design is a very loosely coupled design. The View holds a reference to the ViewModel, and the ViewModel holds a reference to the Model. The rest is done by the data-binding and commanding infrastructure of WPF.

The consequences of MVVM are the following:

1. Hard to Dabug because Databinding is  Declarative.
2. The typical relationship between a ViewModel and the corresponding Views is one-to-many, but there are also situations where that is not necessarily true. In general, any business logic and input-handling business logic (selection tracking, and so on) is kept in the ViewModel.
3. There are situations when one ViewModel is aware of another ViewModel within the same application. Such situations arise when there is a master-subordinate relationship between two ViewModels or when a ViewModel represents a single item (for example, the visual representation state of a single contact). When this happens, one ViewModel can represent a collection of ViewModels.

Othere Reference :http://msdn.microsoft.com/en-us/library/ff798384.aspx

Advertisement