MVVM

What is MVVM?

The Model View ViewModel (MVVM) is an architectural pattern, not to be confused with a software 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 which support Event-driven programming, such as HTML5, Windows Presentation Foundation (WPF) and Silverlight.
MVVM, like many other design patterns, facilitates a “separation of concerns. This design principle was first introduced by Edsger W. Dijkstra in his 1974 paper “On the role of scientific thought” and is closely related to the Unix Philosophy. It holds that a program should be separated in distinct sections, such that each section addresses a separate concern.
Put otherwise: every part of the program should do one thing and do it well.
The benefits gained by this approach are multiple but the most important ones are maintainability and testability trough unit testing.
MVVM facilitates this by a clear separation of the development of the graphical user interface(either as markup language or GUI code) from the development of the business logicor back end logic known as the model (also known as the data model to distinguish it from the view model).
The view model of MVVM is a value converter: 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. The view model may also implement a mediator pattern organising access to the backend logic around the set of use cases supported by the view.
MVVM was designed to make use of data binding functions in WPF to better facilitate the separation of view layer development from the rest of the pattern by removing virtually all GUI code (“code-behind”) from the view layer.Instead of requiring user interface developers to write GUI code, they can use the framework markup language (e.g., XAML) and create bindings to the view model, 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 for higher productivity. Even when a single developer works on the entire code base a proper separation of the view from the model is more productive as the user interface typically changes frequently and late in the development cycle based on end-user feedback.[1]

M for Model

The first M of the MVVM pattern refers to the Model. The model in the MVVM pattern encapsulates business logic and data. Business logic is defined as any application logic that is concerned with the retrieval and management of application data and for making sure that any business rules that ensure data consistency and validity are imposed.
In other words: the Model contains all data for the application but, and this is important, without any presentational formatting.
An example of this would be a contact list. This contact list would, for example, store a persons first name, last name and e-mail address as a list of discrete contact models. Each of these models would have a field for first name, last name and e-mail address.
As you can imagine there might be a requirement to have a “name formatting” option somewhere on the screen where you can display contacts by first name – last name or last name – first name. This information is considered presentational formatting and should not be stored in the data layer. Doing so would violate the “separation of concerns”: the data layer does not know, or care, how it’s data is used or displayed. It’s only responsibility is storing data and making sure that this data is valid before storing it.

V for View

The view contains everything that makes up the GUI: input fields, buttons, JavaScript, styling etc.
Crucially, this is also the only thing it contains. The view contains no (business) logic other then the data bindings to the model.

VM as in View Model
The view model is a “model of the view” meaning it is an abstraction of the view that also serves in mediating between the view and the model which is the target of the view data bindings. It could be seen as a specialized aspect of what would be a controller (in the MVC pattern) that acts as a converter that changes model information into view information and passes commands from the view into the model. The view model exposes public properties, commands, and abstractions.
The view model is also responsible for retrieving or manipulating data items that are to be displayed in the view through data binding. This includes data items from (web)services!
This would mean, for our contact list example, that the view model is responsible for the display order of the contact as either first name – last name or last name – first name trough one or more properties. This could be implemented by having a property on the view model called “FullName” that would return both the first and last name of a contact. The formatting could be controlled by reading another property on the view model called “OrderBy” when the get function of the “FullName” property gets called. Because the view model is responsible for converting data from the model to the view and vice versa via its properties the view model makes the use of ValueConverters superfluous and unnecessary in 99% of all cases.
The view model has been likened to a conceptual state of the data as opposed to the real state of the data in the model. The term “View model” is a major cause of confusion in understanding the pattern when compared to the more widely implemented MVC or MVP patterns. The role of the controller or presenter of the other patterns has been substituted with the framework binder (e.g., XAML) and view model as mediator and/or converter of the model to the binder.

MVVM vs MVP vs MVC

Although MVVM, MVP and MVC are all closely related to one another there are some crucial differences as shown in the diagrams below:

[source: https://msdn.microsoft.com/en-us/library/ff647859.aspx]

MVC

MVC is a compound pattern where view and controller have strategy pattern implementations and View and Model are kept synchronised trough the observer pattern. In practise this means that a view can have multiple controllers which can be interchanged based upon the needs of the view, for example using a different controller depending on the type of user that’s logged in. In turn, the controller can use different models depending on the state and needs of the application. An example of this would be loading different user models depending on the privileges of the user that’s logged in. Important to note is that a controller knows nothing of the view that´s using it.
As with MVVM the view contains all the GUI elements and the model the data for the application.
The controller contains the logic that alters the model depending on the events triggered by the GUI. The view in its turn subscribes to changes on the model via the observer pattern. This ensures that changes to the model are reflected in the state of the user interface. A commonly used example is that of a pc, keyboard and monitor where the pc is the model, the keyboard the controller and the monitor the view. A user types something on the keyboard (controller) that updates the data in the pc (model) which in turn updates the monitor (view).
Strictly speaking the view is responsible for formatting the data from the model. This makes MVC harder to unit test from the perspective of the view unless a view-model, as with MVVM, is added that handles formatting. If no such view-model is present it’s becomes very difficult to unit test the formatting logic that goes on in the view.

MVP

The two main differences between MVC and MVP are that the presenter, the controller in MVC, knows about and communicates with the view and that the presenter is responsible for responding to events from the model and in turn updating the view. In MVP the presenter formats the data from the model before updating the view with it. In MVC this is the responsibility of the view. This makes the view in MVP a passive view whereas the view in MVC is actively formatting data, making it an active view.
The net result of this is that MVP is easier to unit test than MVC: the view can be replaced completely with a unit test module without impacting the functionality of the application.

[1]Parts of text are sourced from: http://en.wikipedia.org/wiki/MVVM