Model–view–viewmodel: Difference between revisions

The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that originated from Microsoft as a specialization of the Model View Presenter design pattern introduced by Martin Fowler^[1] specific for the Windows Presentation Foundation. Largely based on the Model-view-controller pattern (MVC), MVVM is targeted at modern UI development platforms (Windows Presentation Foundation (WPF) and Silverlight in particular) with the idea that the developer is of an artistic View developer than a Developer more oriented toward “traditional” development (i.e. 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^[2]. 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^[2] 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). MVVM newness means that it simply has not had as many opportunities for its potential to be explored.

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.

Broadly speaking^{[2] [3] [4]}, 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 the data access layer representing the real state content.

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. ^[5]

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 quite new relatively speaking, and that new toolsets, walkthroughs, or patterns, such as Onyx, the Microsoft WPF Toolkit, Crack.net, and Caliburn 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 ^[6], 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 a considerable excess of metadata in an application. Given these two limitations, MVVM may have a practical minimum and maximum size for the type of application it can support, suggesting it may not do well with large enterprise applications.

The third is that the exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems^[7]. Additionally, because of the nature of the semantics of data bindings, critics suggest that the ViewModel does not directly describe the View.

• Model View Controller
• Model View Presenter