the MVVM Pattern

The MVVM Pattern

The Model-View-ViewModel pattern can be used on all XAML platforms. Its intent is to provide a clean separation of concerns between the user interface controls and their logic.

There are three core components in the MVVM pattern: the model, the view, and the view model. Each serves a distinct and separate role. The following illustration shows the relationships between the three components.

The components are decoupled from each other, thus enabling:

Components to be swapped
Internal implementation to be changed without affecting the others
Components to be worked on independently
Isolated unit testing
In addition to understanding the responsibilities of the three components, it’s also important to understand how the components interact with each other. At the highest level, the view “knows about” the view model, and the view model “knows about” the model, but the model is unaware of the view model, and the view model is unaware of the view.

The view model isolates the view from the model classes and allows the model to evolve independently of the view.

View

The view is responsible for defining the structure, layout, and appearance of what the user sees on the screen. Ideally, the view is defined purely with XAML, with a limited code-behind that does not contain business logic.

A view can have its own view model, or it can inherit its parent’s view model. A view gets data from its view model through bindings, or invoking methods on the view model. At run time, the view changes when UI controls respond to view model properties raising change notification events.

There are several options for executing code on the view model in response to interactions on the view, such as a button click or item selection. If the control is a Command Source, the control’s Command property can be data-bound to an ICommand property on the view model. When the control’s command is invoked, the code in the view model will be executed. In addition to commands, behaviors can be attached to an object in the view and can listen for either a command to be invoked or event to be raised. In response, the behavior can then invoke an ICommand on the view model or a method on the view model.

Model

The model in MVVM is an implementation of the application’s domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.

View Model

The view model acts as an intermediary between the view and the model, and is responsible for handling the view logic. Typically, the view model interacts with the model by invoking methods in the model classes. The view model then provides data from the model in a form that the view can easily use. The view model retrieves data from the model and then makes the data available to the view, and may reformat the data in some way that makes it simpler for the view to handle. The view model also provides implementations of commands that a user of the application initiates in the view. For example, when a user clicks a button in the UI, that action can trigger a command in the view model. The view model may also be responsible for defining logical state changes that affect some aspect of the display in the view, such as an indication that some operation is pending.

In order for the view model to participate in two-way data binding with the view, its properties must raise the PropertyChanged event.

View models satisfy this requirement by implementing the INotifyPropertyChanged interface and raising the PropertyChanged event when a property is changed. Listeners can respond appropriately to the property changes when they occur.

For collections, the view-friendly System.Collections.ObjectModel.ObservableCollection is provided. This collection implements collection changed notification, relieving the developer from having to implement the INotifyCollectionChanged interface on collections.

Connecting View Models to Views

MVVM leverages the data-binding capabilities in Silverlight to manage the link between the view and view model, along with behaviors and event triggers. These capabilities limit the need to place business logic in the view’s code-behind.

There are many approaches to connecting a view model to a view, including direct relations and container-based approaches. However, all share the same aim, which is for the view to have a view model assigned to its DataContext property.

Views can be connected to view models in a code-behind file, or in the view itself.

Code-Behind

A view can have code in the code-behind file that results in the view model being assigned as its DataContext property. This could be as simple as a view instantiating a new view model and assigning it to its DataContext, or injecting a view model into a view using an inversion-of-control container.

However, connecting a view model to a view in a code-behind file is discouraged as it can cause problems for designers in both Visual Studio and Microsoft Expression Blend® design software.

View

If a view model does not have any constructor arguments, the view model can be instantiated in the view as the view’s DataContext. A common approach to doing this is to use a view model locator. This is a resource which exposes the application’s view models as properties that individual views can data bind to. This approach means that the application has a single class that is responsible for connecting view models to views. In addition, it still leaves developers free to choose to manually perform the connection within the view model locator, or by using a dependency injection container.

The Benefits of MVVM

MVVM enables a great developer-designer workflow, providing these benefits:

During the development process, developers and designers can work more independently and concurrently on their components. The designers can concentrate on the view, and if they are using Expression Blend, they can easily generate sample data to work with, while the developers can work on the view model and model components.
The developers can create unit tests for the view model and the model without using the view. The unit tests for the view model can exercise exactly the same functionality as used by the view.
It is easy to redesign the UI of the application without touching the code because the view is implemented entirely in XAML. A new version of the view should work with the existing view model.
If there is an existing implementation of the model that encapsulates existing business logic, it may be difficult or risky to change. In this scenario, the view model acts as an adapter for the model classes and enables you to avoid making any major changes to the model code.