On the MVP

What is MVP?

MVP is a UI architecture pattern and a variant of MVC for event-driven application frameworks. The MVP's M and V correspond to the model and view in MVC, and p instead of the controller, which is more in the interaction between model and View,presenter.

The relationship between three people:

Only Presenter,view that can interact directly with the model can call model indirectly through presenter. The model is independent of view and is not related to the UI processing Logic presenter. M does not exist in the actual operation, if M can be understood as the combination of the BLL and the DAL.

Presenter relies on an abstraction of the view that is iview.

MVP's PV/SC:

Pv:passive view, which is a passive view, the UI element controls defined in the view are not controlled by V itself, but rather passively handed to p to manipulate.

The UI elements in V are exposed as attributes, that is, when the master defines the iview, the UI element-based attributes are defined so that p can manipulate the view.

However, you cannot expose the control directly as an attribute:

public interface IView

{

TextBox Textboxusername{set;}

}

This makes the presenter and the View technology platform binding in the invisible.

Through the interface and implementation of the interface v implementation of the value of the property to implement the corresponding control of the data binding operations, and leave the operation of the data in V.

public interface IView

{

String Displayinfo{set;}

}

public partial class View:baseview,iview

{

public string DisplayInfo

{

public string DisplayInfo

{

Set

{

This. Textboxusername.text = value;

}

}
}

PV makes the UI processing logic all defined on the presenter. For some rich clients, the interface can be a lot of members, and the same p has fine-grained control of V at the control level, which increases the complexity of p, so there is the SC mode.

Sc:supervising Controller; Transfer simple UI processing logic such as data binding and formatting display data to V; P remains the driver, V passive, user-v-p (-m)-V.

Interaction rules for V and P (SC):

Whether the relationship between PV and Sc,m\v\p has not changed, V is just the front-end customer agent to show the data, p is how to deal with customer interaction behavior decision-maker.

The data is P actively "push" to V, and V only send user notifications to p, are unidirectional; So the method called by presenter in IView should have no return value. The interaction between p/v can be achieved by invoking a method in iview, or by registering the event.

Summary:

MVP is just a UI architecture pattern, it embodies the relationship between the m/v/p, V is only the P "push" the data display, it does not maintain the state of the data, and P is the decision-maker;

In iview, it is best to include only the main method, not the attribute, in the V State required by P when receiving the notification of the view sent, rather than through the view's properties;

On the MVP