学习ASP.NET MVC框架揭秘笔记-PV与SC

1. pv与sc

解决view难以测试最好的办法就是让他无须测试。如果view不需要测试，其先决条件就是让它尽可能不涉及ui处理逻辑，这就是pv模式的目的所在。
如果我们纯粹的采用pv模式来设计view意味着我们需要将view中的ui元素通过属性的形式暴露出来。具体来说，当我们为view定义接口的时候，需要定义基于ui元素的属性使presenter可以对view进行细粒度操作，但这并不意味着我们直接将view上的控件暴露出来。
举个例子，假如我们开发的hr中有这样一个界面，界面上有一个包含所有部门列表的dropdownlist，还有一个是显示员工列表的gridview，还有一个查询按钮，我们可以通过查询按钮来讲选择的部门的员工显示出来。
如果为该view定义一个接口iemployeeview我们不能如下所示的代码将上述的两个控件直接以属性的形式显示出来。针对具体控件类型的数据绑定属于view的内部细节，不能体现在表示用于抽象view的接口中。

public interface iemployeeview
{
	dropdownlist     departments{	  get; }
	gridview	 employees  {     get;}
}

正确的接口和实现该接口的view应该采用如下的定义方式：presenter通过对属性departments和employees赋值来实现对相应dropdownlist和gridview的数据绑定，同时通过属性selecteddepartment得到用户选择的筛选部门。为了尽可能让接口只暴露必需的信息，我们还特意将对属性的读/写作了控制。

 

public interface iemployeeview
{
	ienumerable			departments{  set;}
	string					selecteddepartment{   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模式将所有的ui处理逻辑全部定义在presenter上，意味着所有的ui处理逻辑都可以被测试，从可测试性的角度来看这是一种不错的选择。但它要求将view中可供操作的ui元素定义在对应的接口中，对于一些复杂的富客户端（rich client）应用的view来说，接口成员的数量可能会变得很多。另外，由于presenter需要在控件级别对view进行细粒度的控制，这往往会使原本简单的逻辑复杂化。这种情况下我们往往采用sc模式。

在sc模式下，为了降低presenter的复杂度，我们倾向于将诸如数据绑定和显示数据格式化这样简单的ui处理逻辑转移到view中，这些处理逻辑会体现在view实现的接口中，尽管view从presenter接管了部分ui处理逻辑，但presenter依然是整个三角关系的驱动者，view被动的地位依然没有改变。对于用户作用在view上的交互操作，view本身并不进行响应，它只会将交互请求转发给presenter，后者在独立完成相应的处理流程（可能涉及针对对model的调用）之后会驱动view对用户交互请求进行响应。