MVC, MVP, MVVM comparisons and differences (bottom)

Original: MVC, MVP, MVVM comparison and difference (bottom)

I am very grateful for the attention we have received from the previous article. Some friends in the comments, hope to quickly out the next article. Because of their limited understanding of these patterns, this is a bit late. For these models of comparison, is to combine their own understanding, some places may not be accurate, but only to highlight their own views, can not be a good idea? Welcome you to shoot bricks. :)

Read the catalogue:

Four. MVP mode

The idea of 4.1 MVP

4.2 UI Interface Interface

4.3 The bridge between Presenter--model and view

4.4 MVP's code structure and timing diagram

4.5 MVP Model Summary

Five. MVVM mode

Design idea of 5.1 MVVM pattern

5.2 MVVM Pattern Structure diagram

Six. MVC, MVP, and MVVM pattern Usage Scenario Summary

Four, MVP mode

MVP Mode is also a classic interface mode. The MVP's M represents model, V is view, and P is presenter.
The complete code in the following example can be downloaded here: WINFORMMVP source
You can also compare the Artech of this article in the park to talk about v-p interaction in MVP mode

The idea of 4.1 MVP

the MVP model seems to me to be a real sense of isolating the details and complexity of the view pattern . Why do you say:
Because in other modes v represents the UI interface, it is an HTML page, a XAML file, or a WinForm interface. But in MVP mode, V represents an interface, an interface that abstracts the UI interface. interface means that any interface that implements the interface can reuse existing presenter and model code.

4.2 UI Interface Interface

to understand the MVP well, there is the ability to interface the UI interface . Look at the following interface, the red flag of the user control abstraction, you can get the following interface

 Public Interface Iuseradd {        event  EventHandler useraddevent;        string Get Set ; }        string Get Set ; }}

The 2 input boxes in the interface are abstracted into two properties of username and Userage. The Click event of the Save button is abstracted into the event useraddevent. The code that implements the interface in WinForm is as follows:

 Public Partial classUseradd:usercontrol, Iuseradd { Public EventEventHandler useraddevent;  Public stringUserName {Set{ This. Txbname.text =value;} Get{return  This. Txbname.text;} }        Public stringUserage {Set{ This. Txbage.text =value;} Get{return  This. Txbage.text;} }        PublicUserAdd () {InitializeComponent (); }       Private voidbtnAdd_Click (Objectsender, EventArgs e) {           if(Useraddevent! =NULL) Useraddevent ( This, E); }    }

Take the Userage attribute below to explain the magic of UI interface. When the backend code to get the age value on the interface, just need get property, to update the interface display, just need set property.
At this time, the back-end code for the interface operation, is abstracted to the userage properties of the operation, that is, and the specific interface display is irrelevant.

4.3 The bridge between Presenter--model and view

In the back-end code mentioned above, p and M are included. M, like MVC, refers to logical code. P is the bridge between the model and view, which is responsible for combining the corresponding model with the view.

For the above Iuseradd, the corresponding presenter code is:

 Public classUseraddpresenter:ipresenter {Private ReadOnlyIuser _model; Private ReadOnlyIuseradd _view; Private ReadOnlyApplicationfacade _facade = applicationfacade.instance;//The facade here is for communication between presenter, and the full code can be seen in detail .//in the presenter constructor, the view and model are passed in as arguments        PublicUseraddpresenter (Iuser model, Iuseradd view) {_model=model; _view=view;        Wireupviewevents (); }       Private voidwireupviewevents () {_view. Useraddevent+=_view_useradd; }      //when the Useradd event of the view is triggered, the data in the UI is obtained, the model logic is called and the new user is added. //simultaneously sends the user_added message to the system (the other UI part of the system receives the message, such as the DataGrid here, which is refreshed after it receives the user_added)       Private void_view_useradd (Objectsender, EventArgs e) {            varuser =NewUser {Name=_view. UserName, Age=Convert.ToInt32 (_view.           Userage)}; _model.            AddItem (user); _facade.        SendNotification (applicationfacade.user_added); }}

4.4 MVP's code structure and timing diagram

The code structure and timing diagram of the MVP here will help to understand the MVP pattern better.

4.5 MVP Model Summary

In the MVP, presenter completely separates the model from the view, and the main program logic is implemented in presenter. Furthermore, presenter is not directly related to the specific view, but interacts through a well-defined interface, allowing the presenter to be kept constant when the view is changed, that is, reuse! Not only that, we can also write Test view, simulate the user's various operations, so as to achieve the test of presenter-without the need to use automated testing tools. We can even test the logic of presenter by writing a mock Object (that is, an interface that implements the model and view, but no concrete content) when the model and view are not finished.

The MVP Advantage

1, the model and the view completely separate, we can modify the view without affecting the model
2. Models can be used more efficiently because all interactions occur in one place--presenter internal
3, we can use a presener for multiple views without changing the logic of presenter. This feature is very useful because view changes are always more frequent than models.
4. If we put logic in presenter, then we can test the logic out of the user interface (unit test)

Five, the design idea of the MVVM pattern 5.1 MVVM pattern

In the MVVM pattern, a viewmodel and a view match, which does not have the IView interface in the MVP, but the full and view bindings, all changes in the view are automatically updated to ViewModel. Any changes to the ViewModel are also automatically synchronized to the view display.

The reason this automatic synchronization is possible is that the properties in ViewModel implement an interface such as observable, which means that when a property's set method is used, the property modification event is triggered at the same time, so that the bound UI is automatically refreshed. (in WPF, this observable interface is inotifypropertychanged; in Knockoutjs, it is implemented by the function ko.observable () and ko.observrablecollection ())

So MVVM is a step ahead of the MVP, in the MVP, V is the interface iview, which solves the interface UI coupling; While MVVM simply integrates seamlessly with ViewModel and UI, ViewModel directly represents the UI. But MVVM does this by relying on specific platforms and technologies, such as WPF and Knockoutjs, which is why ViewModel does not need to implement interfaces because, in essence, the use of the MVVM pattern for specific platforms and technologies is a platform that cannot replace the UI. .

5.2 MVVM Pattern Structure diagram

Here is the structure diagram of the MVVM pattern, which helps to understand the MVVM pattern more easily:

Six, MVC, MVP and MVVM pattern Usage Scenarios Summary

Because it is not possible to support bidirectional binding of data and interfaces as well as monitoring of events in WinForm like WPF, MVP is the best choice in WinForm.
Using knockout in WPF and HTML interfaces, observable is implemented, so use MVVM. (It should be said that WPF was designed for use with MVVM)
In a Web application, MVC is the best choice because HTTP is working in a request-and-response manner and cannot remain connected until the message passing between presenter in MVP and ViewModel in MVVM and the interface are bound.