Learning about the ASP. net mvc Framework-PV and SC
1. The best solution for PV and SC to solve View's difficulty in testing is to prevent him from testing. If View does not need to be tested, the prerequisite is that it does not involve the UI processing logic as much as possible, which is the purpose of the PV mode.
If we use the PV mode to design the View, we need to expose the UI elements in the View in the form of attributes. Specifically, when we define an interface for the View, we need to define Attributes Based on the UI elements so that the Presenter can perform fine-grained operations on The View, however, this does not mean that the controls on the View are directly exposed.
For example, if the developed HR system has such an interface, there is a DropDownList containing the list of all departments, a GridView displaying the list of employees, and a query button, you can use the query button to display the selected Department employees.
If you define an IEmployeeView interface for this View, the code shown below cannot directly display the preceding two controls as attributes. Data Binding for specific control types belongs to the internal details of the View and cannot be reflected in the interface that represents the abstract View.
public interface IEmployeeView{DropDownList Departments{ get; }GridView Employees { get;}}
The correct interface and View for implementing this interface should adopt the following definition method: Presenter binds the data of the corresponding DropDownList and GridView by assigning values to the attributes of deployments and Employees, you can also use the SelectedDepartment attribute to obtain the selected filtering department. In order to make the interface expose only necessary information as much as possible, we also specifically control the reading/writing of attributes.
public interface IEmployeeView{IEnumerable
Departments{ set;}StringSelectedDepartment{ get;}IEnumerable
Employees{ set;}}public partial class EmployeeView : page , IEmployeeView{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 the UI processing logic on the Presenter, which means that all the UI processing logic can be tested. This is a good choice from the perspective of testability. However, it requires that you define the UI elements available for operations in the View in the corresponding interface. For View of some complex Rich Client applications, the number of interface members may increase. In addition, because the Presenter needs to control the View in Fine Granularity at the control level, this will often complicate the original simple logic. In this case, we usually adopt the SC Mode.
In SC mode, to reduce the complexity of the Presenter, we tend to move simple UI processing logic such as data binding and displaying data formatting to the View, these processing logics are reflected in the View-Implemented interfaces. Although the View takes over some UI processing logics from the Presenter, the Presenter is still the driver of the entire triangular relationship, the passive position of View remains unchanged. For interactive operations on the View, the View itself does not respond. It only forwards the interactive request to the Presenter, after independently completing the corresponding processing process (which may involve calling the Model), the latter will drive the View to respond to the user interaction request.