Model View ViewModel
Translations of this material:
- into French: Translation of "Model View ViewModel". Translation is not started yet.
Submitted for translation by lawrence 26.08.2010
- into Russian: Модель - Представление - Модель Представления. private, 5% translated in draft.
Submitted for translation by Abonec 22.08.2010
The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that 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 (Windows Presentation Foundation and Silverlight) in which there is a User Experience (UX) developer who has different requirements than a more “traditional” developer (i.e. oriented toward business logic and back end development). The View-Model of MVVM is “basically a value converter on steroids” meaning that the View-Model is responsible for exposing the data objects from the Model in such a way that those objects are easily managed and consumed. In this respect, the View-Model is more Model than View, and handles most if not all of the View’s display logic (though the demarcation between what functions are handled by which layer is a subject of ongoing discussion and exploration).
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 UX needs rather than programming or business logic, allowing for the layers of an application to be developed in multiple work streams.
Microsoft MVP Josh Smith reported that
"In 2005, John Gossman, currently one of the WPF and Silverlight Architects at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler's Presentation Model, in that both patterns feature an abstraction of a View, which contains a View's state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF to simplify the creation of user interfaces. In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms."
As the MVVM pattern is designed to support WPF and Silverlight, both recent creations that came with the .NET Framework 3.0 which was released on 21 November 2006, this pattern is only newly available to the public, as opposed to MVC or Model View Presenter (MVP).
Several Microsoft Architects working on WPF and Avalon have written extensively about MVVM in online media, including creator John Gossman, Microsoft MVP Josh Smith, and Microsoft Program Manager Karl Shifflett as well as other sources. Because of the newness of the pattern, there is a great deal of continuing discussion regarding what tools can be developed to support the pattern, selection of where to place different kinds of supporting code in the pattern, the best methods for data binding, and how to expose data within the ViewModel.
The Microsoft Patterns & Practices team is currently working on adding MVVM support to the next version of Prism (called Prism v4).
Broadly speaking, the Model-View-ViewModel pattern attempts to gain both the advantages of separation of functional development provided by MVC as well as leveraging the advantages of XAML and the Windows Presentation Foundation by binding data as far back (meaning as close to the Model) as possible while using the XAML, ViewModel, and any Business Layer’s inherent data checking features to validate any incoming data. The result is that the Model and Foundation drive as much of the operations as possible, minimizing the need for “code behind,” especially in the View.
Elements of the MVVM pattern include:
Model: as in the classic MVC pattern, the model refers to either (a) an object model that represents the real state content (an object-oriented approach), or (b) the data access layer that represents that content (a data-centric approach).
View: as in the classic MVC pattern, the view refers to all elements displayed by the GUI such as buttons, windows, graphics, and other controls.
ViewModel: the ViewModel is a “Model of the View” meaning it is an abstraction of the View that also serves in data binding between the View and the Model. It could be seen as a specialized aspect of what would be a Controller (in the MVC pattern) that acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions. The ViewModel has been likened to a conceptual state of the data as opposed to the real state of the data in the Model.
Controller: some references for MVVM also include a Controller layer or illustrate that the ViewModel is a specialized functional set in parallel with a Controller, while others do not. This difference is an ongoing area of discussion regarding the standardization of the MVVM pattern.
There are currently three main areas of criticism regarding the MVVM pattern.
The first is that MVVM currently lacks standardization from Microsoft both in implementation and in toolsets. For example, the community has some lack of clarity about where and whether to implement View logic in the View layer or the ViewModel. Given that the MVVM pattern is still relatively new, and that new tool-sets, walkthroughs, or patterns, such as Onyx, the Microsoft WPF Toolkit, Caliburn, MVVM Light Toolkit, and Calcium are being released, this problem may be solved over time. Microsoft has announced in discussion boards that the MVVM template pattern will be released in Visual Studio 2010.
The second comes from MVVM creator John Gossman himself, who points out that the overhead in implementing MVVM is “overkill” for simple UI operations. He also states that for larger applications, generalizing the View layer becomes more difficult. Moreover, he illustrates that data binding, if not managed well, can result in considerable memory consumption in an application.
The third is that the exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems. Additionally, because of the nature of the semantics of data bindings, critics suggest that the ViewModel does not directly describe the View.