MVP,终于把界面分离出来了
目前web开发中面临的一个问题是,很难分清楚哪些是程序员负责的，哪些是美工负责的。在同一个公司还好办，沟通容易，协调也简单。如果是多方合作的项目，一方负责界面一方负责程序，这样分工就很难，由于界面是和一些控制逻辑邦定在一起的，这部分工作很难说是属于哪方，并且涉及界面的部分也难以并行进行。
如现在的一个项目，A方：负责页面（html，aspx）B方：负责程序。今天A方把几个页面调整了一下关系，明天又把弹出的对话框改成页面，后天又在页面上加了几个文本框……，A的调整很可能涉及到B的工作，即使业务逻辑没有改变，页面改变时B也要做一些代码的调整。B很希望有一种方式可以从这种情况下解脱出来，B希望界面改变时自己不修改任何代码，A的修改对B是透明的。
MVC可能是一个选择，但他解耦出来的是M，见图（最后有两个详细的图）：
V和C关联还很紧密，MV，MC之间可以用observer模式，这样形成了弱关联，但仍然会遇到开始时的问题。
对业务的封装很多，如B为A提供一个充值接口，这样业务不改变时B不会去修改代码。能不能通过一种方式，把界面也抽象出一个接口，把此接口提供给A，这样在界面修改时，B就不用做代码的修改了。B就从此解脱了（太高兴了，终于可以……）。
提供界面接口的模式被成为MVP，MVC的变种。可以参考下面的文章：
http://www.microsoft.com/china/msdn/library/architecture/architecture/architecturetopic/MVP.mspx
这篇文章通过一个例子说明了MVP，但是他涉及到了很多其他的东西如：nunit，反到把MVP给隐藏掉了。文章带的代码很好，提供了很好的分层方式，对说明MVP不合适，但在实践的项目中却是很好的模型。
下面MVP的类图，View是UI，IView是B要给A定义的界面接口，这样界面改变时（如，上面说的几种情况），只要接口不改变，B就不用修改代码。Presenter类似于MVC的C，但是他要比C负责更多的东西。
下面是例子的类图，要比上面单纯的MVP复杂一些，增加了一个Service层，此层分离了P和域模型、数据层。此处的UI是指上图的View和IVIew，此图也并没有详细的说明例子的类关系，只有把此图和上图结合才能比较详细的说明例子中的类（把UI用View和Iview替换掉，不想自己画了）。
解决方案中包含14个项目其中六个是测试项目。8个项目中DataAccess、Domain、DTO、ValueObject是和数据有关系的属于M（可细分为Domain和DA）；Controls和UI指V；Presentation是指P；Task指Service。可以看出关系还是很复杂的，6个测试项目中还包含UI的测试。
V的代码：
public partial class ViewCustomers : Page,IViewCustomerView
{
private ViewCustomerPresenter presenter; protected override void OnInit(EventArgs e)
{
base.OnInit(e); presenter = new ViewCustomerPresenter(this); this.customerDropDownList.SelectedIndexChanged += delegate { presenter.DisplayCustomerDetails();
}; } protected void Page_Load(object sender, EventArgs e) { if (! IsPostBack) { presenter.Initialize(); } } public ILookupList CustomerList { get { return new WebLookupList(this.customerDropDownList);} } public string CompanyName { set { this.companyNameLabel.InnerText = value; } } public string ContactName { set { this.contactNameLabel.InnerText = value; } } //省略
}其中属于B的工作是IViewCustomerView 的实现，属于IView，这是为实现MVP，B必须增加的接口，虽然增大了部分工作量，但为了以后少修改还是十分值的。另一个是ViewCustomerPresenter的实现，属于P，类似于MVC的C，P在此例子中通过Task（图中的Service）和DTO、Domain关联，并没有直接访问他们，隔离了业务逻辑和P,用了Facede模式，能适应多种域模型，如以后用webservice提供数据。。
P的实现：可见P依赖于IView和Modle（同过ICustomerTask），Service和P的作用要包含MVC的C，在此例子中C主要是由Service实现的。
public class ViewCustomerPresenter { private readonly IViewCustomerView view; private readonly ICustomerTask task; public ViewCustomerPresenter(IViewCustomerView view) : this(view, new CustomerTask()) {} //依赖注入：DI，IOC public ViewCustomerPresenter(IViewCustomerView view, ICustomerTask task) { this.view = view; this.task = task; } public void Initialize() { task.GetCustomerList().BindTo(view.CustomerList); } public void DisplayCustomerDetails() { int? customerId = SelectedCustomerId; if (customerId.HasValue) { CustomerDTO customer = task.GetDetailsForCustomer(customerId.Value); UpdateViewFrom(customer); } }//省略 } Modle部分很简单，DataAccess封装了通用的数据库访问；Domain域模型；DTO域到对象类的转换；ValueObject是辅助DTO的。分了四个项目，很清楚，不过实际上也可以不用分这么多。
Controls项目是为了测试UI而加上的（当然还可以分离UI的功能），虽然属于V的部分，即A的工作，但是也可以和UI项目合在一起。此项目和UI都用到了ILookupList（DTO），因此V还是依赖于DTO的，ILookupList是列表框的更高层的抽象，代码：
public class WebLookupList : ILookupList { private ListControl underlyingList; public WebLookupList(ListControl underlyingList) { this.underlyingList = underlyingList; } public void Add(ILookupDTO dto) { underlyingList.Items.Add(new ListItem(dto.Text, dto.Value)); } public void Clear() { underlyingList.Items.Clear(); } public ILookupDTO SelectedItem { get { ListItem item = underlyingList.SelectedItem; return new SimpleLookupDTO(item.Value, item.Text); } } }
这样只要IViewCustomerView接口定下来，A所要求的界面就和B再无关系了。
看了MVP，这下B终于开心了，因为A和B的所负责的部分分的很清晰；定义接口以后就可以完全的并行开始工作；最重要的是界面改变时，B可以开心做做其他工作，而不必天天被A烦。
此后，B遇到有关界面的项目时，就可以提供给A一个IView接口，这样只要接口不改变，界面不论怎么变都和B无关了，即使A换成WinForm。
例子中涉及到很多接口，完全是面向接口编程，我觉得有些是没有必要的如Domain项目中的接口，只所以还提供接口是为了测试，但有些是不能少的，如ILookupList，是很好的面向对象的例子。
附：两个MVC图
续：http://www.cnblogs.com/bluewater/archive/2007/07/17/821549.html
