Asp. NET summary of MVC, MVP, MVVM comparison and distinction (ii) _ Practical skills

The last one gets everyone's attention, thank you very much. Because of their understanding of these models is also limited, the comparison of these models, is a combination of their own understanding, some places may not be accurate, but only the light of their own point of view, can not be? You are welcome to pat Bricks. :)

Copy Code code as follows:

Read the Table of contents:

Four. MVP Model

The thought of 4.1 MVP

Interface of 4.2 UI interface

The bridge between 4.3 presenter--model and view

4.4 MVP code structure and sequence diagram

4.5 MVP Model Summary

Five. MVVM mode

Design idea of 5.1 MVVM model

5.2 MVVM Pattern Structure diagram

Six. MVC, MVP and MVVM mode usage Scenario Summary

Four, MVP mode

The MVP model is also a classic interface model. The MVP m represents model, V is view, P is presenter.
The complete code in the following example can be downloaded here: WINFORMMVP source
You can also compare this article analysis of v-p interaction in MVP model and case sharing

The thought of 4.1 MVP
The MVP model seems to me to be a real way of isolating view details and complexity of the pattern. Why do you say this:
Because v in other modes represents the UI interface, it is an HTML page, a XAML file, or a WinForm interface. But v in MVP mode 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.

Interface of 4.2 UI interface
To understand the MVP well, you have to have the ability to interface the UI. Look at the interface below and abstract the Red Flag user control to get the following interface

Copy Code code as follows:

public interface Iuseradd
{
Event EventHandler Useraddevent;
String UserName {get; set;}
String Userage {get; set;}
}

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

Copy Code code as follows:

Public partial class Useradd:usercontrol, Iuseradd
{
public event EventHandler Useraddevent;
public string UserName
{
set {This.txbName.Text = value;}
get {return this.txbName.Text;}
}

public string Userage
{
set {This.txbAge.Text = value;}
get {return this.txbAge.Text;}
}

Public Useradd ()
{
InitializeComponent ();
}

private void btnAdd_Click (object sender, EventArgs e)
{
if (useraddevent!= null) useraddevent (this, e);
}
}

Here's a userage attribute to explain the magic of UI interface. When the backend code gets the age value on the interface, only the Get property is required, and the Set property is required to update the display of the interface.
At this time, the back-end code for the interface operation, is abstracted into the userage attribute of the operation, that is, and the specific interface display has nothing to do.

The bridge between 4.3 presenter--model and view
The back-end code mentioned above contains P and M. M is the same as MVC, which refers to logical code. P is a bridge between model and view, responsible for the corresponding model and view together.

For the above Iuseradd, the corresponding presenter code is:

Copy Code code as follows:

public class Useraddpresenter:ipresenter
{
Private ReadOnly Iuser _model;
Private ReadOnly Iuseradd _view;
Private readonly Applicationfacade _facade = applicationfacade.instance; The façade here is used for communication between presenter, the full code can be seen in detail

Presenter constructor, the view and model are passed in as arguments

Public Useraddpresenter (Iuser model, Iuseradd view)
{
_model = model;
_view = view;
Wireupviewevents ();
}

private void Wireupviewevents ()
{
_view. Useraddevent + = _view_useradd;
}

When the view Useradd event is triggered, get the data in the UI, invoke model logic, and add new users.
Send user_added messages to the system at the same time (other UI parts of the system receive messages, such as the DataGrid here, which is refreshed after receiving user_added)
private void _view_useradd (object sender, EventArgs e)
{
var user = new User
{
Name = _view. UserName,
Age = Convert.ToInt32 (_view. Userage)
};
_model. AddItem (user);
_facade. SendNotification (applicationfacade.user_added);
}
}

4.4 MVP code structure and sequence diagram
The code structure and timeline diagrams in the MVP can help you understand the MVP model better.

4.5 MVP Model Summary
In the MVP, presenter completely separates the model and view, and the main program logic is implemented in presenter. Moreover, presenter is not directly related to the specific view, but through the definition of the interface to interact, so that changes in the view can be maintained presenter, that is, reuse! Not only that, we can also write the test view, simulate the various operations of the user, so as to achieve the presenter test-without the need to use automated testing tools. We can even test the logic of presenter by writing mock Object, which implements the interface of model and view, but has no specific content, when both model and view are not complete.

The MVP Advantage

1, the model and view completely separate, we can modify the view without affecting the model
2, you can use the model more efficiently, because all the interactions happen in one place--presenter internal
3, we can use a presener for multiple views without changing the logic of the presenter. This feature is 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, MVVM mode

Design idea of 5.1 MVVM model
In MVVM mode, a ViewModel and a view match, which does not have the IView interface in the MVP, but the full and view bindings, and all changes in view are automatically updated to ViewModel. Any changes to the ViewModel are also automatically synchronized to the view display.

This automatic synchronization is possible because properties in ViewModel implement interfaces such as observable, which means that when a property's set is used, the property-modified event is triggered and the bound UI is automatically refreshed. (in WPF, this observable interface is inotifypropertychanged; in Knockoutjs, it is implemented through function ko.observable () and ko.observrablecollection ())

So MVVM a step higher than the MVP, in MVP, V is the interface iview, to solve the interface UI coupling; and MVVM simply use ViewModel and UI seamlessly, ViewModel directly represent 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 of the reliance on specific platforms and technologies, which essentially uses the MVVM pattern to replace the UI's use platform. .

5.2 MVVM Pattern Structure diagram
Here is the MVVM pattern, which helps to understand the MVVM pattern more easily:

VI, MVC, MVP and MVVM mode usage Scenario Summary

The MVP is the best choice in WinForm because it does not support bidirectional binding of data and interfaces and event monitoring in WinForm, as in WPF. The
WPF and HTML interfaces use knockout to achieve observable, so use MVVM. (It should be said that WPF is designed for use with MVVM)
in Web applications, MVC is the best option because HTTP is not always connected because it works together in a request-and-response fashion, so it is not possible to reach the presenter between the MVP and the ViewModel and interface in MVVM.