目前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负责更多的东西。
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。 附:两个MVC图
|
|