What is MVP and MVVM?

Question

It is very common to talk about the MVC (Model-View-Controller) standard. But the acronyms MVP (Model-View-Presenter) and MVVM (Model-View-View-Model) are very poorly cited. What they are and what their relationship to MVC?

Answer 1

Recapping what you probably already know:

Model

• Contains the connection to the database or how to access the data
• has the necessary logic to process the data in the database or other source
• processes the data obtained at the source and puts it in the form necessary for the other layers to use properly.

Data relevant to the system is processed here.

Some of these functions may be on a separate layer, but only the model communicates with it.

View

• Has all the design and formatting of the user interface
• usually have UI-specific validations
• processes the data obtained in the UI to be made available in a suitable way for other layers.

That’s where there really is a way to present the data. And only the visual presentation is made. There is no processing of the system data.

What differentiates the 3 architectural patterns is the communication between the layers and the way the third layer is organized and executed.

MVP

The MVP is an evolution of the MVC that communicates bidirectionally with the other layers, preventing the Model must communicate directly with View without going through the Controller and the latter is fundamental to user interaction. MVP decouples functions and makes the architecture even more modular.

• The layer Presenter is aware of everything that occurs in the other two layers and makes them aware of what she is doing
• user interaction is done primarily by View, and may delegate to the Presenter certain tasks
• there is a one-to-one relationship between these layers. In this relationship there is a reference of the View to the Presenter but not the opposite.

IS possible link data from View with the Model through data Binding. This occurs in the variation Supervising Controller, as opposed to variation Passive View where the View essentially only has the design of the UI.

To View can contain code to manipulate the UI.

Because of total decoupling, testing becomes a simpler task.

Windows Forms is an example of MVP.

See more in MSDN Magazine

MVVM

The MVVM is a small evolution of the MVP on one side and a setback on the other. In it the Viewmodel is not aware of what occurs in the View but this is aware of what occurs in the Viewmodel. In the case of Model both are aware of what occurs in each.

The name is given because it adds properties and operations to Model to meet the needs of View, so he creates a new model for the visualization.

It is possible to associate several Views for a Modelview. It is common that the Views are defined in a declarative form (HTML/CSS, XAML, etc.).

The data Binding is made between the View and the Viewmodel.

With this standard you can reduce the amount of code to maintain. Some automations are possible by having all the necessary information on Viewmodel.

Viewmodel is only a more suitable model for a specific view (or more than one).

It is a standard that is closely linked to WPF. Its creation is credited to one of the WPF developers. Although this standard is not required, it is adopted by almost all programmers using WPF. Knockoutjs is an example for the web. Also used with Angularjs.

This illustration of microsoft documentation shows how communication takes place:

See more in MSDN Magazine

Completion

It is interesting to follow the recommendation of the adopted technology and implement the standard that experts consider the most suitable for it. But this should not be done blindly. It is necessary to evaluate the specific situation. You can escape a little from what the pattern preaches when there’s a reason for it. Of course, if you need to change a lot, maybe the pattern and maybe even the technology is wrong for the problem. Break a rule if it benefits the application.

One of the most relevant sources on the subject is the Martin Fowler’s website. I also like of this blog by the examples.

Answer 2

Basically, the difference is that MVC has the architecture based on Controllers, whereas the MVVM has the architecture based on Viewmodels, and MVP has an extra layer of presentation, called Presenter.

And what’s the difference between them?

The Controller exposes the Model pure, exactly the data representation that should be persisted on the basis. In the case of MVVM, what is exposed is a Viewmodel, that is, another data representation that is handled before it is saved. In MVP, the layer Presenter makes the midfield between Model and View, acting as an observer of both. They are exposed to the View events that make the reception and processing of data by the Model.

Okay, but how does it work?

Not having a Controller in the case of the MVVM and the MVP, what happens is that the whole logic of data harmonisation and the relationships between entities (primary function of the layer Controller) is all resolved in View (presentation).

Specifically speaking of the MVP, there is intense communication in two ways:

• Model sends information to the View;
• View responds to the Model that was successfully assembled.

Or else:

• View sends data to the Model for a query or data persistence;
• Model responds whether operation was successful or not.

When recommended to use?

For systems where the View can be intensely enriched (as in systems that use a lot of Javascript, for example), both Designs work well.

MVP has a slight advantage over MVVM by enabling the mock layer View for unit testing.

There is an easy-to-notice drawback, which is in the case that there are multiple layers of presentation (e.g., HTML/CSS/Javascript and REST API). In this case, the MVVM and the MVP become unviable.

Known Examples

• MVVM: Meteor
• MVP: ASP.NET Web Forms, WPF (formerly known as Prism)