MVC, MVP, and model2[the next article]

[Previous] By adopting the MVC pattern, we can define the rendering of visual UI elements, the UI processing logic, and the business logic separately in view, controller, and model, but there is no strict restriction on MVC for the interactions between the three. The most typical is to allow the view and model to bypass the controller direct interaction, view not only through the call model to obtain the data needs to be presented to the user, model can also directly notify the view let it perceive the state of change. When it is true that MVC is applied to specific project development, whether it is a GUI based desktop application or a Web-UI based Web application, the programs we write can be more difficult to maintain than autonomous views if the interaction between model, view, and controller is not more restrictive.

Today we see MVC as a pattern, but Trygve M. Reenskau, the original author of MVC, actually treats MVC as an example (PARADIGM), which can be seen in the applications programming In Smalltalk-80 (TM): The description of MVC in the "How to" use Model-view-controller (MVC) can be seen: in the MVC paradigm the user input, the modeling Of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, Each specialized to its task.

The difference between patterns and paradigms is that the former can be applied directly to specific applications, while the latter only provides some basic guidelines. In my opinion, MVC is a very broad concept, and any design based on model, view, and controller to decompose UI applications can become MVC. When we design UI applications using the idea of MVC, we should set a stricter rule for the boundaries of model, view, and controller, and the interaction between them, based on the characteristics of the application framework (such as Windows Forms, WPF, and Web Forms). There have been some variations of MVC (Varation) in the evolution of software design, which follow the basic principles defined in MVC. Let's now briefly discuss some of the common MVC variants.

First, the MVP

MVP is a widely used architecture based pattern that uses an event-based application framework, such as ASP.net Web forms and Windows Forms applications. The M and V in the MVP correspond to the model and view of MVC, while P (presenter) naturally replaces the controller in MVC. But the MVP is not only reflected in the transformation from controller to presenter, but also in the interaction between model, view and presenter.

The messy interactions between elements in the MVC pattern are completely resolved in the MVP model as long as they allow view and model to bypass the controller for individual "communication". As shown in the following illustration, the model can be invoked directly by Presenter,view only indirectly through presenter. The independence of model is really embodied here, not only with the rendering of visual elements (View) and the UI Processing Logic (presenter). The application of the MVP is user-driven rather than model-driven, so model does not need to actively notify the view to remind the State of the change.

The MVP not only avoids the coupling between view and model, but further reduces presenter's reliance on view. As shown in Figure 1-2, presenter relies on an abstract view, which is the interface iview of the view implementation. The most immediate benefit of this is that the UI processing logic defined in presenter becomes easy to test. Since presenter's dependency behavior on view is defined in the interface iview, we only need to mock a view that implements the interface to test the presenter.

The interaction between the three elements of the MVP is embodied in two aspects, namely View/presenter and Presenter/model. The interaction between presenter and model is very clear, only reflected in the presenter to model of one-way call. and the interaction between view and presenter is the core of the whole MVP, whether the original intention of the MVP's separation can be embodied in the specific application depends largely on whether the interaction between the two is correct. According to the interaction between view and presenter and the scope of the view itself, Martin Folwer the MVP into two modes: PV (passive View) and SOC (supervising Controller).

PV and Soc

The best way to solve a view that is difficult to test is to leave it without testing, and if the view does not need to be tested, the prerequisite is to let it not involve UI processing logic as much as possible, which is the purpose of the PV mode. As the name suggests, PV (passive view) is a passive view, and the operation of the UI elements (such as controls) contained therein is not manipulated by the view itself, but by the presenter.

If we design view purely using PV mode, we need to expose the UI elements in the definition view to the form of attributes. Specifically, when we define an interface for the view, we need to define the attributes based on the UI element so that presenter can manipulate the view fine-grained, but that does not mean that we expose the control directly on the view. For a simple example, the HR system we developed has a Web page in the following illustration that is used to get a list of employees based on the department.

Now, with the ASP.net Web form application to cover this page, let's discuss how to define an interface that uses the PV mode view. For presenter, there are two controls for which the view operates, one that contains all the departmental lists, and the other is the GridView that displays the list of employees. DropDownList When the page loads, presenter binds the departmental list to the DropDownList, while the list containing all the employees is bound to the GridView. When the user selects a department and clicks the "Query" button, view sends a query request containing the filter department to presenter, which filters out the appropriate employee list and binds it to the GridView.

If we define an interface Iemployeesearchview for the view, we cannot expose these two controls directly as attributes, as shown in the following code. The choice of the control type for data binding belongs to the internal details of the view (for example, for the display of the departmental list, we can choose DropDownList or ListBox) and cannot be reflected in the interface that represents the abstract view. On the other hand, the UI processing logic that is ideally defined in presenter should be independent of the specific technology platform, and if the control type is involved in the interface, it will undoubtedly bind the presenter to the specific technical platform.

   1:public Interface Iemployeesearchview
   2: {
   3:     DropDownList departments {get;}
   4:     GridView Employees {get;}
   5:}

The correct interface and view (a Web page) that implements the interface should be defined in the following way. Presenter the DropDownList and the GridView by assigning values through attribute departments and employees, and obtains the filtering department selected by the user through the attribute selecteddepartment. In order to allow the interface to expose only the necessary information, we deliberately control the reading and writing of the attribute.

1:public Interface Iemployeesearchview
2: {
3:ienumerable<string> departments {set;}
4:string selecteddepartment {get;}
5:ienumerable<employee> Employees {set;}
6:}
7:
8:public partial class Employeesearchview:page, Iemployeesearchview
9: {
10://other Members
11:public ienumerable<string> Departments
12: {
13:set
14: {
15:this. Dropdownlistdepartments.datasource = value;
16:this. Dropdownlistdepartments.databind ();
17:}
18:}
19:public string selecteddepartment
20: {
21:get {return this. Dropdownlistdepartments.selectedvalue;}
22:}
23:public ienumerable<employee> Employees
24: {
25:set
26: {
27:this. Gridviewemployees.datasource = value;
28:this. Gridviewemployees.databind ();
29:}
30:}
31:}