dinghao

记录成长点滴

 

MVP,终于把界面分离出来了

        目前web开发中面临的一个问题是,很难分清楚哪些是程序员负责的,哪些是美工负责的。在同一个公司还好办,沟通容易,协调也简单。如果是多方合作的项目,一方负责界面一方负责程序,这样分工就很难,由于界面是和一些控制逻辑邦定在一起的,这部分工作很难说是属于哪方,并且涉及界面的部分也难以并行进行。

如现在的一个项目,A方:负责页面(htmlaspxB方:负责程序。今天A方把几个页面调整了一下关系,明天又把弹出的对话框改成页面,后天又在页面上加了几个文本框……,A的调整很可能涉及到B的工作,即使业务逻辑没有改变,页面改变时B也要做一些代码的调整。B很希望有一种方式可以从这种情况下解脱出来,B希望界面改变时自己不修改任何代码,A的修改对B是透明的。

MVC可能是一个选择,但他解耦出来的是M,见图(最后有两个详细的图):

                                                       

VC关联还很紧密,MVMC之间可以用observer模式,这样形成了弱关联,但仍然会遇到开始时的问题。

对业务的封装很多,如BA提供一个充值接口,这样业务不改变时B不会去修改代码。能不能通过一种方式,把界面也抽象出一个接口,把此接口提供给A,这样在界面修改时,B就不用做代码的修改了。B就从此解脱了(太高兴了,终于可以……)。

提供界面接口的模式被成为MVPMVC的变种。可以参考下面的文章:

http://www.microsoft.com/china/msdn/library/architecture/architecture/architecturetopic/MVP.mspx

这篇文章通过一个例子说明了MVP,但是他涉及到了很多其他的东西如:nunit,反到把MVP给隐藏掉了。文章带的代码很好,提供了很好的分层方式,对说明MVP不合适,但在实践的项目中却是很好的模型。

下面MVP的类图,ViewUIIViewB要给A定义的界面接口,这样界面改变时(如,上面说的几种情况),只要接口不改变,B就不用修改代码。Presenter类似于MVCC,但是他要比C负责更多的东西。

                                    
    下面是例子的类图,要比上面单纯的
MVP复杂一些,增加了一个Service层,此层分离了P和域模型、数据层。此处的UI是指上图的ViewIVIew,此图也并没有详细的说明例子的类关系,只有把此图和上图结合才能比较详细的说明例子中的类(把UIViewIview替换掉,不想自己画了)。

                                                                           
       
解决方案中包含14个项目其中六个是测试项目。8个项目中DataAccessDomainDTOValueObject是和数据有关系的属于M(可细分为DomainDA);ControlsUIVPresentation是指PTaskService。可以看出关系还是很复杂的,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,这是为实现MVPB必须增加的接口,虽然增大了部分工作量,但为了以后少修改还是十分值的。另一个是ViewCustomerPresenter的实现,属于P,类似于MVCCP在此例子中通过Task(图中的Service)和DTODomain关联,并没有直接访问他们,隔离了业务逻辑和P,用了Facede模式,能适应多种域模型,如以后用webservice提供数据。

P的实现:可见P依赖于IViewModle(同过ICustomerTask),ServiceP的作用要包含MVCC,在此例子中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都用到了ILookupListDTO),因此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终于开心了,因为AB的所负责的部分分的很清晰;定义接口以后就可以完全的并行开始工作;最重要的是界面改变时,B可以开心做做其他工作,而不必天天被A烦。

此后,B遇到有关界面的项目时,就可以提供给A一个IView接口,这样只要接口不改变,界面不论怎么变都和B无关了,即使A换成WinForm。
   例子中涉及到很多接口,完全是面向接口编程,我觉得有些是没有必要的如Domain项目中的接口,只所以还提供接口是为了测试,但有些是不能少的,如ILookupList,是很好的面向对象的例子。

附:两个MVC

                                       
                                                                  
续:http://www.cnblogs.com/bluewater/archive/2007/07/17/821549.html

posted on 2006-12-11 20:28  思无邪  阅读(6038)  评论(24编辑  收藏  举报

导航