Comparison and differences between MVC, MVP, and MVVM (II)

Thanks for your attention in the previous article. In comments from some friends, I hope to come up with the next article soon. This article is too late because I have limited understanding of these models. The comparison between these models is based on your own understanding. Some areas are not necessarily accurate, but only by showing your own point of view can you give a reference? You are welcome to make a brick. :)

Reading directory:

Iv. MVP Mode

4.1 MVP Thoughts

4.2 UI Interface

4.3 Presenter -- bridge between Model and View

4.4 MVP code structure and sequence diagram

4.5 MVP mode Summary

V. MVVM Mode

5.1 design idea of MVVM Mode

5.2 MVVM mode structure

Vi. Summary of the use cases of MVC, MVP, and MVVM Modes

4. MVP Mode

MVP ModeIt is also a classic interface mode. In MVP, M represents Model, V is View, and P is Presenter.
The complete code in the following example can be downloaded here: WinformMVP source code
We can also compare Artech's article to talk about the issue of V-P interaction in MVP mode.

4.1 MVP Thoughts

In my opinion, the MVP mode is a true mode of isolating View Details and complexity. Why:
In other modes, V represents the UI, an html page, a XAML file, or a winform interface. However, in MVP mode, V represents an interface that abstracts the UI. The interface means that any interface that implements this interface can reuse the existing Presenter and Model code.

4.2 UI Interface

To better understand MVPs, you must have the ability to interface the UI. In the following interface, abstract the User Control marked in red to obtain the following interface:

Public interface IUserAdd {event EventHandler UserAddEvent; string UserName {get; set;} string UserAge {get; set ;}}

The two input boxes in the interface are abstracted into two attributes: UserName and UserAge. The click event of the Save button is abstracted as the event UserAddEvent. The code for implementing this interface in winform is 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);        }    }

The following describes the magic of UI Interface Based on the UserAge attribute. To get the age value on the interface, the backend Code only needs the get attribute. to update the display of the interface, only the set attribute is required.
At this time, the operations of the backend code on the interface are abstracted into operations on the UserAge attribute, that is, they are irrelevant to the specific interface display.

4.3 Presenter -- bridge between Model and View

The backend Code mentioned above contains the same logic code as P and M. M in MVC. P is the bridge between Model and View, and is responsible for combining the corresponding Model and View.

For the above IUserAdd, the corresponding Presenter code is:

Public class UserAddPresenter: IPresenter {private readonly IUser _ model; private readonly IUserAdd _ view; private readonly ApplicationFacade _ facade = ApplicationFacade. instance; // The facade is used for communication between Presenter. For details, see the complete code. // In the Presenter constructor, pass view and model as parameters to public UserAddPresenter (IUser model, IUserAdd view) {_ model = model; _ view = view; WireUpViewEvents ();} private void WireUpViewEvents () {_ view. us ErAddEvent + = _ view_UserAdd;} // when the view UserAdd event is triggered, obtain the data in the UI, call model logic processing, and add a new user. // Send the User_ADDED message to the system at the same time (Other UI parts of the system receive the message, such as the DataGrid here, which will be 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

Here, the MVP code structure and sequence diagram can help you better understand the MVP mode.

 

 

4.5 MVP mode Summary

In MVP, Presenter completely separates Model and View, and implements the main program logic in Presenter. In addition, the Presenter is not directly associated with a specific View, but interacts with the specific View through a defined interface, so that the Presenter can be retained when the View is changed! In addition, we can also compile the View for testing to simulate various user operations, so as to test the Presenter-without using automated testing tools. When neither Model nor View is complete, we can write Mock Object (that is, the Model and View interfaces are implemented, but there is no specific content) to test the Presenter logic.

Advantages of MVP

1. The model and view are completely separated. We can modify the view without affecting the model.
2. The model can be used more efficiently, because all interactions occur in one place-inside the Presenter.
3. We can use a Presener for multiple views without changing the Presenter logic. This feature is very useful because views change more frequently than models.
4. If we put the logic in the Presenter, we can test the logic (unit test) from the user interface)

V. MVVM mode 5.1 design philosophy of MVVM Mode

In MVVM mode, a ViewModel matches a View. It does not have the IView interface in MVP, but is completely bound to the View. modifications and changes in all views are automatically updated to the ViewModel, any changes to the ViewModel are automatically synchronized to the View.

The reason for this automatic synchronization is that the attributes in ViewModel all implement interfaces such as observable. That is to say, when the attribute set method is used, the attribute modification event is triggered at the same time, automatically refresh the bound UI. (In WPF, the observable interface is INotifyPropertyChanged; In knockoutjs, it is implemented through the ko. observable () and ko. observrableCollection () functions)

Therefore, MVVM is a step more upgraded than MVP. In MVP, V is the interface IView to solve the UI coupling. MVVM simply uses ViewModel and UI to integrate seamlessly, viewModel can directly represent the UI. however, MVVM relies on specific platforms and technologies to achieve this, such as WPF and knockoutjs. This is why ViewModel does not need to implement interfaces, because of the dependence on specific platforms and technologies, the MVVM mode cannot replace the platform used by the UI.

5.2 MVVM mode structure

Here is the structure diagram of the MVVM mode, which can help you better understand the MVVM mode:

 

Vi. Summary of the use cases of MVC, MVP, and MVVM Modes

As winform does not support bidirectional binding of data and interfaces and event monitoring like WPF, MVP is the best choice in winform.
Knockout is used in the WPF and html interfaces to implement observable. Therefore, MVVM is used. (It should be said that WPF is designed for MVVM)
In web applications, because http works collaboratively based on request and response methods, the connection status cannot be maintained, therefore, message transmission between Presenter in MVP and binding between ViewModel and interface in MVVM cannot be achieved. Therefore, MVC is the best choice.