Shulou(Shulou.com)06/02 Report--

This article is about what the commonly used MVC variants are. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

The variant of MVC adopts the MVC pattern, so we can define the rendering of visual UI elements, UI processing logic and business logic in View, Controller and Model respectively, but MVC has no strict restrictions on the interaction between them. The most typical is to allow View and Model to interact directly around Controller. View can get the data that needs to be presented to the user by calling Model, and Model can also directly notify View to perceive the change in state. When we apply MVC to specific project development, whether it is GUI-based desktop applications or Web UI-based Web applications, without more stringent restrictions on the interaction between Model, View and Controller, the programs we write may be more difficult to maintain than autonomous views.

Today we regard MVC as a Pattern, but Trygve M. H. Reenskau, who originally proposed MVC, regards MVC as a Paradigm, which can be seen from its description of MVC in Applications Programming in Smalltalk-80 (TM): How to use Model-View-Controller (MVC): 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 for its task.

The difference between patterns and examples is that the former can be directly applied to specific applications, while the latter only provides some basic guidelines. In my opinion, MVC is a very broad concept, and any design that decomposes UI applications based on Model, View, and Controller can become MVC. When we use the idea of MVC to design UI applications, we should set a stricter rule on the boundaries of Model, View and Controller and the interaction between them according to the characteristics of development frameworks (such as Windows Forms, WPF and Web Forms).

In the course of the development of software design, there are some variants of MVC (Varation), which follow the basic principles defined in MVC. Let's briefly discuss some commonly used MVC variants.

MVPMVP is a widely used UI architecture pattern, which is suitable for event-driven application frameworks such as ASP.NET Web Forms and Windows Forms applications. M and V in MVP correspond to Model and View in MVC respectively, while P (Presenter) naturally replaces Controller in MVC. But MVP is not only reflected in the transformation from Controller to Presenter, but also in the interaction between Model, View and Presenter.

The "messy" interaction between elements in MVC mode is mainly reflected in allowing View and Model to "communicate" separately, bypassing Controller, which is completely resolved in MVP mode. As shown in figure 1-2, the only thing that can interact directly with Model is that Presenter,View can only call Model indirectly through Presenter. The independence of Model is truly demonstrated here, not only with the presentation of visual elements (View), but also with UI processing logic (Presenter). Applications that use MVP are user-driven rather than Model-driven, so Model does not need to actively notify View that the state has changed.

Figure 1-2 interaction between Model-View-Presenter

MVP not only avoids the coupling between View and Model, but also further reduces Presenter's dependence on View. As shown in figure 1-2, Presenter relies on an abstract View, the interface IView implemented by View, which has the most immediate benefit of making the UI processing logic defined in Presenter easy to test. Because the dependency behavior of Presenter on View is defined in the interface IView, we only need Mock, a View that implements the interface, to test Presenter.

The interaction between the three elements of MVP is reflected in two aspects, namely, View/Presenter and Presenter/Model. The interaction between Presenter and Model is clear, only reflected in Presenter's one-way call to Model. The interaction mode between View and Presenter is the core of the whole MVP. Whether the original intention of MVP for the separation of concerns can be reflected in the specific application largely depends on whether the interaction between the two is correct. According to the interaction between View and Presenter and the terms of reference of View itself, Martin Folwer divides MVP into two modes: PV (Passive View) and SC (Supervising Controller).

The best way for PV and SC to solve the difficulty of testing View is to make it unnecessary to test. If View does not need testing, the prerequisite is to keep it as free of UI processing logic as possible, which is what the PV pattern is all about. As the name implies, PV (Passive View) is a passive View in which operations on UI elements (such as controls) are not actively controlled by View itself, but passively controlled by Presenter.

If we simply use the PV pattern to design View, it means that we need to expose the UI elements in View in the form of attributes. Specifically, when we define an interface for View, we need to define attributes based on UI elements so that Presenter can perform fine-grained operations on View, but this does not mean that we directly expose the controls on View. As a simple example, suppose we develop a HR system with a Web page shown in figure 1-3, through which we can get a list of employees in a department.

Figure 1-3 employee query page

Now that we design this page through the ASP.NET Web Forms application, let's discuss how the interface of View should be defined if the PV mode is adopted. For Presenter, View has two controls for it to manipulate, one is a DropDownList that contains a list of all departments, and the other is a GridView that displays a list of employees. When the page loads, Presenter binds the department list to DropDownList, while the list containing all employees is bound to GridView. When the user selects a department and clicks the query button, View forwards the query request including the filtering department to Presenter, which filters out the corresponding employee list and binds it to GridView.

If we define an interface IEmployeeSearchView for the View, we cannot expose the above two controls directly as properties as shown in the code shown. Data binding for specific control types belongs to the internal details of View (for example, we can choose DropDownList or ListBox for the display of department lists) and cannot be reflected in the presentation of interfaces for abstract View. In addition, ideally, the UI processing logic 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 technology platform.

Public interface IEmployeeSearchView

{

DropDownList Departments {get;}

GridView Employees {get;}

}

The correct interface and the View (a Web page) that implements the interface should be defined as follows. Presenter realizes the data binding to the corresponding DropDownList and GridView by assigning values to the attributes Departments and Employees, and gets the filtering department selected by the user through the attribute SelectedDepartment. In order to make the interface expose only the necessary information as much as possible, we deliberately control the reading / writing of attributes.

Public interface IEmployeeSearchView

{

IEnumerable Departments {set;}

String SelectedDepartment {get;}

IEnumerable Employees {set;}

}

Public partial class EmployeeSearchView: Page, IEmployeeSearchView

{

/ / other members

Public IEnumerable Departments

{

Set

{

This.DropDownListDepartments.DataSource = value

This.DropDownListDepartments.DataBind ()

}

}

Public string SelectedDepartment

{

Get {return this.DropDownListDepartments.SelectedValue;}

}

Public IEnumerable Employees

{

Set

{

This.GridViewEmployees.DataSource = value

This.GridViewEmployees.DataBind ()

}

}

}

PV mode defines all UI processing logic on Presenter, which means that all UI processing logic can be tested, so it is a good choice from the point of view of testability, but it requires that the operational UI elements in View are defined in the corresponding interface. For some complex rich client (Rich Client) View, the interface members will become many, which will undoubtedly increase the amount of code required for programming. On the other hand, because Presenter needs fine-grained control over View at the control level, this will undoubtedly provide the complexity of Presenter itself, often complicating the original simple logic, in which case we tend to adopt the SC pattern.

In SC mode, in order to reduce the complexity of Presenter, we transfer simple UI processing logic such as data binding and formatting to View, which is reflected in the interface implemented by View. Although View takes over part of the UI processing logic from Presenter, Presenter is still the driver of the whole triangle, and the passive position of View remains unchanged. The View itself does not respond to the user's interaction on the View, but forwards the interaction request directly to the Presenter, which drives the View or creates a new View in response to the user interaction after independently completing the corresponding processing flow (which may involve a call to the Model).

Rules of interaction between View and Presenter (for SC mode) the interaction between View and Presenter is the core of the whole MVP. Whether we can correctly apply the MVP pattern to construct our application mainly depends on whether we can correctly deal with the relationship between View and Presenter. In the triangular relationship composed of Model, View and Presenter, the core is not View but Presenter,Presenter is not the intermediary of View calling Model, but the decision maker who finally decides how to respond to the user interaction behavior.

For example, View is the customer agent delegated by Presenter to the front end, and the customer is naturally the end user. View, as an agent, does not have the power to decide how to handle interactive requests in the form of mouse / keyboard operations, so it reports the request to the principal Presenter. View should send user interaction requests to Presenter in such a tone: "I will send user interaction requests to you now, and I will assist you when you need me." instead of this: "I am now dealing with user interaction requests, I know what to do, but I need your support, because the Model that implements the business logic only trusts you."

For Presenter's process of handling user interaction requests, if the intermediate link needs to involve Model, it will directly initiate a call to Model. If you need the involvement of View (for example, you need to reflect the latest status of Model on View), Presenter will drive View to do the job.

For data bound to View, View should not "pull" back from Presenter, but Presenter should actively "push" to View. From the perspective of message flow (or message exchange mode), whether View completes the notification of user interaction request to Presenter, or Presenter drives View to complete the corresponding UI operation in the process of interaction request processing, it is one-way (One-Way). The reflection on the definition of the API means that either the method that is called by View in Presenter or the method that is called by Presenter in the IView interface is best not returned. If we do not use the form of method calls, we can also achieve the interaction between View and Presenter through event registration, and the message flow reflected by the event mechanism is undoubtedly one-way.

View itself only implements simple, independent UI processing logic, and the data it processes should be pushed to it by Presenter in real time, so View does not maintain the data state as much as possible. The interface defined in IView preferably contains only methods, while avoiding the definition of attributes, the state of View required by Presenter should be obtained at once when receiving a user interaction request sent by View, rather than through the properties of View.

Example demonstration: application of SC pattern (S101) in order to give readers a deep understanding of MVP mode, especially the interaction between View and Presenter under this mode, let's do a simple example demonstration now. This example uses the above-mentioned scenario about employee query, and uses ASP.NET Web Forms to build this simple application, and the final effect is shown in figure 1-3. We have demonstrated how IView should be defined in PV mode, so let's take a look at how IView in SC mode is different.

Let's first take a look at how the data types that represent employee information are defined. We represent an employee by having the data type Employee defined below. For simplicity, we define only five attributes that represent the basic information of the employee (ID, name, gender, date of birth, and department).

Public class Employee

{

Public string Id {get; private set;}

Public string Name {get; private set;}

Public string Gender {get; private set;}

Public DateTime BirthDate {get; private set;}

Public string Department {get; private set;}

Public Employee (string id, string name, string gender

DateTime birthDate, string department)

{

This.Id = id

This.Name = name

This.Gender = gender

This.BirthDate = birthDate

This.Department = department

}

}

Model, which contains application status and state operation behavior, is represented by a simple EmployeeRepository type as follows. As shown in the code, the data that represents the list of all employees is maintained through a static field, while GetEmployees returns the list of employees of the specified department, or directly returns the list of all employees if no filtering department is specified or if the specified department character is empty.

Public class EmployeeRepository

{

Private static IList employees

Static EmployeeRepository ()

{

Employees = new List ()

Employees.Add (new Employee, Zhang San, male)

New DateTime (1981, 8, 24), "sales Department")

Employees.Add (new Employee, Li Si, female)

New DateTime (1982, 7, 10), "personnel Department")

Employees.Add (new Employee, Wang Wu, male)

New DateTime (1981, 9, 21), "personnel Department")

}

Public IEnumerable GetEmployees (string department = "")

{

If (string.IsNullOrEmpty (department))

{

Return employees

}

Return employees.Where (e > e.Department = = department) .ToArray ()

}

}

Next let's look at the definition of IEmployeeSearchView as the View interface. As shown in the following code snippet, this interface defines two methods, BindEmployees and BindDepartments, for binding DropDownList based on department list and GridView based on employee list, respectively. In addition, the IEmployeeSearchView interface defines an event DepartmentSelected that is triggered when the user selects a filtering department and clicks the query button. The DepartmentSelected event parameter type is a custom DepartmentSelectedEventArgs, and the attribute Department represents the department selected by the user.

Public interface IEmployeeSearchView

{

Void BindEmployees (IEnumerable employees)

Void BindDepartments (IEnumerable departments)

Event EventHandler DepartmentSelected

}

Public class DepartmentSelectedEventArgs: EventArgs

{

Public string Department {get; private set;}

Public DepartmentSelectedEventArgs (string department)

{

This.Department = department

}

}

Presenter, which is the core of the MVP triangle, is represented by EmployeeSearchPresenter. As shown in the following code snippet, the read-only property type for View is the IEmployeeSearchView interface, while another read-only property, Repository, represents the EmployeeRepository object as Model, both of which are initialized in the constructor.

Public class EmployeeSearchPresenter

{

Public IemployeeSearchView View {get; private set;}

Public EmployeeRepository Repository {get; private set;}

Public EmployeeSearchPresenter (IEmployeeSearchView view)

{

This.View = view

This.Repository = new EmployeeRepository ()

This.View.DepartmentSelected + = OnDepartmentSelected

}

Public void Initialize ()

{

IEnumerable employees = this.Repository.GetEmployees ()

This.View.BindEmployees (employees)

String [] departments =

New string [] {"sales Department", "Purchasing Department", "personnel Department", "IT Department"}

This.View.BindDepartments (departments)

}

Protected void OnDepartmentSelected (object sender

DepartmentSelectedEventArgs args)

{

String department = args.Department

Var employees = this.Repository.GetEmployees (department)

This.View.BindEmployees (employees)

}

}

In the constructor, we register the DepartmentSelected event of View, and the OnDepartmentSelected method, as the event handler, gets the employee list under the user selection department by calling Repository (that is, Model), and the returned employee list implements the data binding on the View by calling the BindEmployees method of View. In the Initialize method, we get a list of all employees by calling Repository and display them on the interface through the BindEmployees method of View. The list of departments as a filter is bound to the View by calling the View's BindDepartments method.

Finally, let's take a look at how Web pages as View are defined. Shown below is the HTML as the main part of the page, and the core part is a DropDownList that binds the list of departments and a GridView that binds the list of employees.

Staff management

Select the inquiry department:

The definition of the background code for the Web page is shown below, which implements two methods (BindEmployees and BindDepartments) and an event (DepartmentSelected) defined in the IEmployeeSearchView interface. A read-only property of the same name that represents Presenter is initialized in the constructor. The Initialize method of the Presenter is called when the page is loaded (Page_Load method), and the event DepartmentSelected is triggered when the query button is clicked (ButtonSearch_Click).

Public partial class Default: Page, IEmployeeSearchView

{

Public EmployeeSearchPresenter Presenter {get; private set;}

Public event EventHandler DepartmentSelected

Public Default ()

{

This.Presenter = new EmployeeSearchPresenter (this)

}

Protected void Page_Load (object sender, EventArgs e)

{

If (! this.IsPostBack)

{

This.Presenter.Initialize ()

}

}

Protected void ButtonSearch_Click (object sender, EventArgs e)

{

String department = this.DropDownListDepartments.SelectedValue

DepartmentSelectedEventArgs eventArgs =

New DepartmentSelectedEventArgs (department)

If (null! = DepartmentSelected)

{

DepartmentSelected (this, eventArgs)

}

}

Public void BindEmployees (IEnumerable employees)

{

This.GridViewEmployees.DataSource = employees

This.GridViewEmployees.DataBind ()

}

Public void BindDepartments (IEnumerable departments)

{

This.DropDownListDepartments.DataSource = departments

This.DropDownListDepartments.DataBind ()

}

}

Thank you for reading! This is the end of this article on "what are the commonly used variants of MVC". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.