界面程序分离思路

时间：2021-10-09 00:24:29
目前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图
界面程序分离思路

界面程序分离思路  
标签：

相关文章