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

This article mainly explains "how to understand the interaction problem of Vmurp in MVP mode". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. please follow the editor's train of thought to study and learn "how to understand the interaction problem of Vmurp in MVP mode".

First, tell me briefly what MVP is.

In terms of hierarchical relationship, MVP belongs to the design pattern of the Presentation layer. For a UI module, all its functions are divided into three parts, which are carried by Model, View and Presenter respectively. Model, View, and Presenter collaborate with each other to complete the presentation of the initial data and the response to user actions, and they have their own division of responsibilities. Model can be seen as the provider of the business logic and data of the module; View is responsible for the visualization of data, corresponding to user interaction events. In general, View implements a corresponding interface; Presenter generally acts as a link between Model and View.

MVP has many variants, of which the most commonly used one is Passive View (passive view). The relationship between Passive View,Model, View, and Presenter is shown in the following figure. There is no direct interaction between View and Modell, and View deals with Model through Presenter. Presenter accepts the UI request from View, completes the simple UI processing logic, calls Model for business processing, and calls View to reflect the corresponding results. View directly depends on Presenter, but Presenter indirectly depends on View, which directly depends on the interface implemented by View. The basic common sense about MVP and Passive View is not the focus of this article, and readers who are not clear about it believe that they can Google out a lot of relevant information, so I will introduce it more here.

II. Summary of the basic characteristics of Passive View model

Passive View, as its name implies, View is passive. So who is taking the initiative? The answer is Presenter. I personally understand Presenter's initiative as follows:

Presenter is the control center of the whole MVP system, not the person who simply processes View requests.

View is only the reporter of user interaction requests. View does not participate in decision-making in response to the logic and processes related to user interaction. The real decision maker is Presenter.

View should send user interaction requests to Presenter in such a tone: "I will send user interaction requests to you now. It is up to you. I will assist you when you need me." it should not be like this: "I handle user interaction requests now. I know what to do, but I need your support, because the Model that implements the business logic only trusts you."

For the data bound to View, View should not "pull" it from Presenter, but Presenter should actively "push" it to View.

View does not maintain data state as much as possible because it only implements simple, independent UI operations; Presenter is the coordinator of the entire system, arranging work for View and Model according to the logic used for interaction.

III. The distance between ideal and reality

In the face of the list of Passive View MVP features, I think it is an ideal state. It is very difficult to achieve such an ideal state as a whole in large projects, especially when the developers of the project do not fully understand the principles of MVP. Some people might say, isn't it bullshit to ask developers to make good use of MVP when they don't know MVP? In fact, this is not to say that developers do not have MVP's concept of separation of concerns at all, but there is no very clear definition of the three roles in MVP (in fact, there is no clear specification for the specific scope of responsibility of Model, View and Presenter). When developing, they will be unconsciously influenced by traditional programming habits and regard Presenter simply as an intermediary for View to call Model. I often say that if you take View as the center and think of Presenter as the middleman between View and Model, this is also called MVP mode, but the P here is not Presenter, but Proxy, Model's agent in View.

Judging from the dependency relationship among Model, View, and Presenter in Passive View, this model fully gives developers a chance to make such a mistake. Note that the arrow from View to Presenter in the figure above indicates that View can call Presenter at will. It is entirely possible for developers to write most of the UI processing logic in View, while Presenter simply makes calls to Model response operations. Because many of my Review's so-called MVP programming methods are written this way. In many cases, you don't even have to analyze the specific code carefully, as you can tell from the number of lines of code in View and Presenter, because View's code is not in the same order of magnitude as Presenter's code.

One of my goals now is to propose a programming model that prevents developers from writing programs as Proxy-based MVP. In my opinion, the only way is to minimize (and impossible to eliminate) View's dependence on Presenter. In fact, for MVP, View only submits user interaction requests to Presenter, that's all. If we implement this dependency of View on Presenter at the framework level, in the end, developers will not need this dependency programmatically. Then I can use certain programming skills to make it impossible for View to access Presenter at all, thus preventing Presenter from becoming the possibility of Proxy.

So, what if you can't get the Presenter, so that View can normally submit the request to Presenter? Very simply, it can be done through the event subscription mechanism. Although View cannot get Presenter, Presenter can get View and let Presenter subscribe to events related to View.

Fourth, make View no longer dependent on Presenter's programming model

Now, we will be able to completely remove View's dependence on Presenter from the final developer's source code through a simple programming mode. To do this, we need to define a series of base classes. First, I create the base class ViewBase for all View, where we directly use Form as the View, while in SCSF View is generally represented by UserControl. ViewBase is defined as follows, and in order to prevent Presenter from being called in View, I define it as a private field. So how do you make a connection between View and Presenter? In this case, through the virtual method CreatePresenter, the concrete View must override the method, or a NotImplementedException exception will be thrown. In the constructor, calling this method is better than assigning a Presenter with a return value.

The copy code is as follows:

Using System

Using System.ComponentModell

Using System.Windows.Forms

Namespace MVPDemo

{

Public class ViewBase: Form

{

Private object _ presenter

Public ViewBase ()

{

_ presenter = this.CreatePresenter ()

}

Protected virtual object CreatePresenter ()

{

If (LicenseManager.CurrentContext.UsageModel = = LicenseUsageModel.Designtime)

{

Return null

}

Else

{

Throw new NotImplementedException (string.Format ("{0} must override the CreatePresenter method.", this.GetType () .FullName))

}

}

}

}

Then, we also create the base class Presenter for all Presenter, and the generic type IView represents the interface of the concrete View implementation. The read-only property of the same name that represents View is assigned in the constructor, and after the assignment is completed, the virtual method OnViewSet is called. A specific Presenter can override this method to register events with View. However, it should be noted that the creation of Presenter is achieved by calling the CreatePresenter method in the constructor of ViewBase, so when OnViewSet is executed, View itself is not fully initialized, so the control of View cannot be manipulated here.

The copy code is as follows:

Namespace MVPDemo

{

Public class Presenter

{

Public IView View {get; private set;}

Public Presenter (IView view)

{

This.View = view

This.OnViewSet ()

}

Protected virtual void OnViewSet ()

{}

}

}

Because Presenter interacts with View through interfaces. Here, because View is reflected in the form of Form, sometimes we have to access some properties, methods and events of Form through this interface, so we need to define the corresponding members on the interface, which is troublesome. At this point, we can choose to define these members in an interface, and the interface of the specific View can inherit that interface. Here, we have created a "base interface" for all the View interfaces. As a demonstration, I now have three event members of Form defined in the street corner IViewBase.

The copy code is as follows:

Using System

Using System.ComponentModell

Namespace MVPDemo

{

Public interface IViewBase

{

Event EventHandler Load

Event EventHandler Closed

Event CancelEventHandler Closing

}

}

5. Demonstration of examples

Above I built a framework for the whole programming model by defining base classes and interfaces, and now we introduce the application of the programming model through a specific example. We use a simple Windows Forms application to simulate the scenario of managing customer information, and the logic is simple: when the program starts, the list of all clients is displayed; the user selects a client and displays the response information in TextBox for editing; after making corresponding changes to the client information, click the OK button to save. The entire operation interface is shown in the following figure:

First, we create the entity class Customer, which, for simplicity, contains only four attributes: Id, FirstName, LastName, and Address:

The copy code is as follows:

Using System

Namespace MVPDemo

{

Public class Customer: ICloneable

{

Public string Id

{get; set;}

Public string FirstName

{get; set;}

Public string LastName

{get; set;}

Public string Address

{get; set;}

Object ICloneable.Clone ()

{

Return this.Clone ()

}

Public Customer Clone ()

{

Return new Customer {

Id = this.Id

FirstName = this.FirstName

LastName = this.LastName

Address = this.Address

}

}

}

}

Then, in order to truly simulate the three roles of MVP, a CustomerModel type is specially created. In fact, in real applications, there is no single type to represent Model. CustomerModel maintains customer list, systematization-related query and update operations. CustomerModel is defined as follows:

The copy code is as follows:

Using System.Collections.Generic

Using System.Linq

Namespace MVPDemo

{

Public class CustomerModel

{

Private IList _ customers = new List {

New Customer {Id = "001", FirstName = "San", LastName = "Zhang", Address= "Su zhou"}

New Customer {Id = "002", FirstName = "Si", LastName = "Li", Address= "Shang Hai"}

}

Public void UpdateCustomer (Customer customer)

{

For (int I = 0; I

< _customers.Count; i++) { if (_customers[i].Id == customer.Id) { _customers[i] = customer; break; } } } public Customer GetCustomerById(string id) { var customers = from customer in _customers where customer.Id == id select customer.Clone(); return customers.ToArray()[0]; } public Customer[] GetAllCustomers() { var customers = from customer in _customers select customer.Clone(); return customers.ToArray(); } } } 接着，我们定义View的接口ICustomerView。ICustomerView定义了两个事件，CustomerSelected在用户从Gird中选择了某个条客户记录是触发，而CustomerSaving则在用户完成编辑点击OK按钮视图提交修改时触发。ICustomerView还定义了View必须完成的三个基本操作：绑定客户列表（ListAllCustomers）；显示单个客户信息到TextBox（DisplayCustomerInfo）；保存后清空可编辑控件（Clear）。 复制代码 代码如下: using System; namespace MVPDemo { public interface ICustomerView : IViewBase { event EventHandler CustomerSelected; event EventHandler CustomerSaving; void ListAllCustomers(Customer[] customers); void DisplayCustomerInfo(Customer customer); void Clear(); } } 事件参数的类型CustomerEventArgs定义如下，两个属性CustomerId和Customer分别代表客户ＩＤ和具体的客户，它们分别用于上面提到的CustomerSelected和CustomerSaving事件。 复制代码 代码如下: using System; namespace MVPDemo { public class CustomerEventArgs : EventArgs { public string CustomerId { get; set; } public Customer Customer { get; set; } } } 而具体的Presenter定义在如下的CustomerPresenter类型中。在重写的OnViewSet方法中注册View的三个事件：Load事件中调用Model获取所有客户列表，并显示在View的Grid上；CustomerSelected事件中通过事件参数传递的客户ID调用Model获取相应的客户信息，显示在View的可编辑控件上；CustomerSaving则通过事件参数传递的被更新过的客户信息，调用Model提交更新。 复制代码 代码如下: using System.Windows.Forms; namespace MVPDemo { public class CustomerPresenter: Presenter { public CustomerModel Model { get; private set; } public CustomerPresenter(ICustomerView view) : base(view) { this.Model = new CustomerModel(); } protected override void OnViewSet() { this.View.Load += (sender, args) =>

{

Customer [] customers = this.Model.GetAllCustomers ()

This.View.ListAllCustomers (customers)

This.View.Clear ()

}

This.View.CustomerSelected + = (sender, args) = >

{

Customer customer = this.Model.GetCustomerById (args.CustomerId)

This.View.DisplayCustomerInfo (customer)

}

This.View.CustomerSaving + = (sender, args) = >

{

This.Model.UpdateCustomer (args.Customer)

Customer [] customers = this.Model.GetAllCustomers ()

This.View.ListAllCustomers (customers)

This.View.Clear ()

MessageBox.Show ("The customer has been successfully updated!", "Successfully Update", MessageBoxButtons.OK, MessageBoxIcon.Information)

}

}

}

}

For a specific View, you just need to implement ICustomerView and handle the response control event (mainly when the user selects the RowHeaderMouseClick event triggered by a record from the Grid and the event that clicks OK). In fact, there is no need for View to handle these events himself, but just trigger the corresponding events and let the event subscribers (Presenter) handle them. You also need to override the CreatePresenter method to complete the creation of the CustomerPresenter. CustomerView is defined as follows:

The copy code is as follows:

Using System

Using System.Windows.Forms

Namespace MVPDemo

{

Public partial class CustomerView: ViewBase, ICustomerView

{

Public CustomerView ()

{

InitializeComponent ()

}

Protected override object CreatePresenter ()

{

Return new CustomerPresenter (this)

}

# region ICustomerView Members

Public event EventHandler CustomerSelected

Public event EventHandler CustomerSaving

Public void ListAllCustomers (Customer [] customers)

{

This.dataGridViewCustomers.DataSource = customers

}

Public void DisplayCustomerInfo (Customer customer)

{

This.buttonOK.Enabled = true

This.textBoxId.Text = customer.Id

This.textBox1stName.Text = customer.FirstName

This.textBoxLastName.Text = customer.LastName

This.textBoxAddress.Text = customer.Address

}

Public void Clear ()

{

This.buttonOK.Enabled = false

This.textBox1stName.Text = string.Empty

This.textBoxLastName.Text = string.Empty

This.textBoxAddress.Text = string.Empty

This.textBoxId.Text = string.Empty

}

# endregion

Protected virtual void OnCustomerSelected (string customerId)

{

Var previousId = this.textBoxId.Text.Trim ()

If (customerId = = previousId)

{

Return

}

If (null! = this.CustomerSelected)

{

This.CustomerSelected (this, new CustomerEventArgs {CustomerId = customerId})

}

}

Protected virtual void OnCustomerSaving (Customer customer)

{

If (null! = this.CustomerSaving)

{

This.CustomerSaving (this, new CustomerEventArgs {Customer = customer})

}

}

Private void dataGridViewCustomers_RowHeaderMouseClick (object sender, DataGridViewCellMouseEventArgs e)

{

Var currentRow = this.dataGridViewCustomers.Rows [e.RowIndex]

Var customerId = currentRow.Cells [0] .Value.ToString ()

This.OnCustomerSelected (customerId)

}

Private void buttonOK_Click (object sender, EventArgs e)

{

Var customer = new Customer ()

Customer.Id = this.textBoxId.Text.Trim ()

Customer.FirstName = this.textBox1stName.Text.Trim ()

Customer.LastName = this.textBoxLastName.Text.Trim ()

Customer.Address = this.textBoxAddress.Text.Trim ()

This.OnCustomerSaving (customer)

}

}

}

Thank you for your reading. the above is the content of "how to understand the interaction problem of Vmurp in MVP mode". After the study of this article, I believe you have a deeper understanding of how to understand the problem of interaction in MVP mode, and the specific use needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.