Popular design patterns have made people’s lives easier since the early days of creating user interfaces for programs. For example, the model-presenter-presenter (MVP) pattern has been popular in various user interface programming platforms. MVP is a variation of the model-presenter-controller pattern that is several decades old. If you’ve never had to use the MVP pattern, below is a brief description of it. What you see on the screen is the view; the data displayed there is the model, and the presenter puts them together. The view needs the presenter to populate the model with data, respond to user input, provide input validation (including by passing this function to the model), and other such tasks. If you need more information about the model-presenter-presenter pattern, I suggest reading Jean-Paul Boodhoo’s August 2006 article “Design Patterns”.
In 2004 Martin Fowler published an article about a template called the Presentation Model (PM). The Presentation Model pattern is similar to MVP in that it separates the presentation from its behavior and state. The curious part of the PM pattern is that it creates an abstraction of the presentation called a presentation model. The representation thus becomes simply the result of processing the presentation model. According to Fowler, the presentation model constantly updates its representation, so they remain synchronized with each other. This synchronization logic exists as code in the presentation model classes.
In 2005, John Gossman, now one of the WPF and Silverlight architects at Microsoft, blogged about the presentation model-presentation-model (MVVM) pattern. MVVM is the same as Fowler’s presentation model in that. both patterns contain a presentation abstraction containing the state and behavior of the presentation. Fowler introduced the presentation pattern as a way to create a platform-independent user interface of a view abstraction, and Gossman proposed MVVM as a standardized way to use core WPF features to simplify the creation of user interfaces. In this sense, I consider MVVM to be a private variant of the more general PM pattern, tailored for WPF and Silverlight platforms.
Glenn Block’s excellent article “Prism: Patterns for building composite applications with WPF” in the September 2008 issue describes Microsoft’s guidance on composite applications for WPF. The term ViewModel is not used. The term presentation model is used to describe the abstraction of a view. However, in this article, I will refer to the pattern by the abbreviation MVVM, and to the view abstraction as a presentation model. In the WPF and Silverlight communities, this terminology is much more common.
Unlike a presenter in MVP, a presentation model does not need to reference a view. The presentation binds to the properties of the presentation model, which in turn represents the data in the model objects and other states needed for that presentation. Bindings between a view and a view model are easy to create because the view model object is set as the DataContext of the view. If values in the view model change, those new values are automatically transferred to the view through data binding. When the user clicks a button in the view, a command in the view model is executed to perform the desired action. All changes to model data are always made by the view model, not the view.
The representation classes are unaware of the existence of the model classes, and the representation model and the model are unaware of the representation. The model actually has no idea at all that the representation model and the representation exist.