Recapping what you probably already know:

Model

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

System-relevant data is processed here.

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

View

• Has all the design and formatting of the user interface
• Usually has specific UI validations
• processes the data obtained in the UI to be made available appropriately to 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 system data.

What differentiates the 3 architecture patterns is the communication between the layers and how the third layer is organized and executed.

MVP

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

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

You can link View data with Model through data binding . This occurs in the Supervising Controller variation, as opposed to the Passive View variation where View essentially only has the UI drawing. The View can contain code to handle 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 MVP on one side and a rollback on another. In it the ViewModel is not aware of what occurs in View but it is aware of what occurs in ViewModel . In the case of Model both are aware of what happens in each.

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

You can associate multiple Views with a ModelView . It is common for Views to be defined declaratively (HTML / CSS, XAML, etc.).

With this pattern you can reduce the amount of code to keep. Some automations are possible because they have all the necessary information in the ViewModel .

ViewModel is just one more suitable model for a specific view (or more than one).

It is a pattern that is closely linked to WPF. Your creation is credited to one of the WPF developers. Although this pattern is not mandatory, it is adopted by almost all programmers using WPF. KnockoutJS is an example for web. It is also often used with AngularJS.

This illustration from Microsoft documentation shows how the communication takes place:

See More on MSDN Magazine

Conclusion

It is interesting to follow the recommendation of the technology adopted and implement the standard that experts consider the most appropriate for it. But this should not be done blindly. The specific situation needs to be assessed. You can run away a little from what preaches the pattern when there is a reason for this. Of course if you need to change a lot, maybe the default 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 website . I also like blog for the examples.

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

And what's the difference between them?

The Controller exposes pure Model , exactly the representation of data that should be persisted on the basis. In the case of MVVM, what is exposed is a ViewModel , that is, another representation of data that is handled before being saved. In MVP, the Presenter layer makes the mid-field between Model and View , acting as an observer of both. They are exposed to View events that do the receiving and processing of data by the Model layer.

Ok, but how does this work?

If there is no Controller in the case of MVVM and MVP, what happens is that all data harmonization logic and entity relationships (primordial < in>) is all resolved in View (presentation).

Specifically speaking about MVP, there is intense two-way communication:

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

Or else:

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

When is it recommended to use?

For cases of systems where View can be heavily 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 mock of the View layer for unit testing.

There is an easy disadvantage to note, which is in the case where there are multiple presentation layers (eg HTML / CSS / JavaScript and REST API). In this case, the MVVM and the MVP become even unviable.

Known Examples

• MVVM: Meteor
• MVP: ASP.NET Web Forms ,