If a developer is used to WPF and MVVM, the latter becomes difficult to distinguish. MVVM is a kind of common language for WPF developers because it is well adapted to the WPF platform, and WPF was created to make it easier to build applications using the MVVM pattern (and others). At Microsoft, MVVM was used internally to develop WPF applications, such as Microsoft Expression Blend, while the core WPF platform was still being built. Many parts of WPF, such as the viewless control model and data templates, use the significant separation of display from state and behavior used in MVVM.
The most important aspect of WPF that makes MVVM a very convenient pattern is the data binding infrastructure. By binding view properties to the view model, a loose coupling of these components is obtained, which completely frees the developer from having to write code in the view model that directly updates the view. The data binding system also supports input validation, providing a standardized path for passing validation errors to the view.
Two other WPF features that make this pattern so useful are data templates and the resource system. Data templates apply views to the view model objects shown in the user interface. You can declare templates in XAML code and let the resource system automatically find and apply these templates for you at runtime. To learn more about data binding and templates, see my July 2008 article “Data and WPF. Customizing data display using data binding and WPF”.
If WPF didn’t have command support, the MVVM pattern wouldn’t be so versatile. In this article, I will show you how a view model can provide commands to a view, thus allowing it to use its functions. If you are not familiar with the command system, I suggest you read Brian Noyes’ extensive article “WPF for Connoisseurs. Getting to Know Routed Events and Commands in WPF”, in the September 2008 issue.
In addition to the WPF (and Silverlight 2) features that make MVVM a natural way to structure an application, this pattern is also popular because the classes of the view model lend themselves easily to unit testing. If the application’s interaction logic is in a set of view model classes, it is easy to write code that tests it. In a sense, views and unit tests are different types of view model consumers. A test suite for an application’s view model provides free and fast regression testing that reduces the cost of maintaining the application in the future.
In addition to the convenience of composing automatic regression tests, the testability of presentation model classes can help to properly design user interfaces for which it is easy to make design themes. When designing an application, you can often decide whether to put something in the view or in the view model by imagining whether you will need to write a unit test that consumes the view model. If you can write unit tests for the view model without creating UI objects, you can also encapsulate the view model completely in a design theme, since it has no dependencies on specific visual elements.
Finally, for developers collaborating with visual designers, using MVVM makes it easy to create a continuous flow of work between the designer and the developer. Since a view is nothing more than an optional consumer of the view model, it is not difficult to remove one view and replace it to represent the view model with a new one. This simple action allows rapid prototyping and evaluation of user interfaces made by the designers.
The development team can focus on creating stable classes of the view model, while the design team can focus on user-friendly views. It takes little more than checking that the correct bindings exist in the view’s XAML file to bring together the results of both teams’ work.