说说MVP模式

初看MVP模式时被它复杂的包含,继承,接口搞晕,View中有Presenter,Presenter中又有View,View又要抽象出IView,View又调用Presenter的方法,Presenter又调用IView的方法.花了点时间算是搞明白了,这里说说自己的理解.

关于MVP模式文章一搜一大把.建议先看看这些文章.

Artceh

http://www.cnblogs.com/artech/archive/2010/04/12/1710681.html

http://www.cnblogs.com/artech/archive/2010/03/25/1696205.html

Jianqiang Bao

http://www.cnblogs.com/jax/archive/2009/10/09/1579404.html

Microsoft

http://www.microsoft.com/china/msdn/library/architecture/architecture/architecturetopic/MVP.mspx?mfr=true

理解MVP模式,其实很简单

借用 Artceh的图片

可以把V和P的交互想象成一个HTTTP请求,View为客户端,Presenter相当于服务器端,处理流程:

1.View发生一些事件,一般就是页面事件,按钮点击事件等.

2.View请求Presenter处理.

3.Presenter整合调度Model的方法处理.

4.Presenter调用View的方法作为回应.

流程就这么简单,搞明白这个基本就差不多了.

开发MVP模式的一般流程

结合实例总结一下用MVP开发的步骤.例子很简单,就是显示一个List.可以显示全部员工,也可以显示属于某个项目的员工.

1.抽象出IView.根据页面功能抽象.可分为两个部分.

请求部分,对应Winform,Webform的各种页面,控件事件,参考Artceh的文章,请求部分应该是自定义事件.在这个例子中,没有按钮点击,也没有下拉框改变,只有页面的load事件,所以请求部分就是一个ViewLoad.

响应部分,是提供给Presenter操作View的,例如显示数据,显示错误提示,清空控件状态等.在这个例子中当然就是把一些数组show出来,考虑到将来有可能有多个控件的数据绑定,所以把数据绑定放在一个方法中,直接this.DataBind()就可以,不用每个控件都绑定一次,简单点的话不要这个PageDataBind也可以.

为了更清晰,我用partial 类,接口把每个关注点分开了.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

//IView namespace WebAppMVP.IView { /// <summary> /// 请求部分,对应各种事件,页面事件,按钮单击事件,下拉框改变事件等等 /// 要在View中封装处理一下,不能直接把对应的事件丢给Presenter /// 所以下面的事件参数为,ListEmployeeEventArgs /// </summary> public partial interface IListEmployeeView { event EventHandler<ListEmployeeEventArgs> ViewLoad; } /// <summary> /// 回应部分 /// </summary> public partial interface IListEmployeeView { void ShowEmployee(ListEmployeeViewModel vm); void PageDataBind(); } }

2自定义请求参数.

请求部分是一个自定义事件,所以ListEmployeeEventArgs是这个事件的自定义参数,通过封装这些参数,就可以把与业务无关的代码过滤掉.在这个页面功能中,因为需要显示属于某个项目的员工,所以参数当然就是ProjectId(Name是多余的,我不想再查询一次,其实只需ProjectId即可).

?

1 2 3 4 5 6 7 8 9

//EventArgs namespace WebAppMVP.IView.EventArgs { public class ListEmployeeEventArgs : System.EventArgs { public int ? ProjectId { get ; set ; } public string Name { get ; set ; } } }

3.同理,一个用作显示的参数也是必要的.

?

1 2 3 4 5 6 7 8 9 10

//ViewModel namespace WebAppMVP.ViewModel { public class ListEmployeeViewModel { public string ProjectName { get ; set ; } public Employee[] Employees { get ; set ; } } }

4.Presenter.

在Presenter中用构造函数注入一个IView.

订阅IView的事件.

事件处理方法中包含两个部分,1根据参数处理业务,2调用IView定义的方法作为回应

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

namespace WebAppMVP.Presenter { public partial class ListEmployeePresenter { IListEmployeeView m_IView { get ; set ; } MockData mockData = new MockData(); public ListEmployeePresenter(IListEmployeeView iview) { this .m_IView = iview; //订阅事件,即View那边发生对应的事件,这里负责处理,责任很大,包括业务逻辑(如果有另外的业务逻辑层,就服务整合和调度) //还要负责如何显示数据(只负责调用IView的方法,具体实现在View中), this .m_IView.ViewLoad += (sender, args) => { #region 业务逻辑 ListEmployeeViewModel vm = new ListEmployeeViewModel(); if (args.ProjectId.HasValue) { vm.ProjectName = args.Name; vm.Employees = mockData.Employees.Where(e => e.Projects.Any(p => p.Id == args.ProjectId.Value)).Take(10).ToArray(); } else { vm.ProjectName = string .Empty; vm.Employees = mockData.Employees.Take(10).ToArray(); } #endregion #region 显示数据,作为回应 this .m_IView.ShowEmployee(vm); this .m_IView.PageDataBind(); #endregion }; } } }

5.View.

这里我也分为三个部分.

初始化部分在View中继承IView,实例化一个Presenter.

?

1 2 3 4 5 6 7 8 9 10 11 12 13

/// <summary> /// 初始化部分,每个页面基本雷同 /// </summary> public partial class ListEmployeeView : System.Web.UI.Page, IListEmployeeView { public event EventHandler<ListEmployeeEventArgs> ViewLoad; private ListEmployeePresenter m_Presenter; protected void Page_Init( object sender, EventArgs e) { m_Presenter = new ListEmployeePresenter( this ); } }

请求部分在对应的页面,控件事件中准备XXXEventArgs参数,触发方法IView的自定义事件.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

/// <summary> /// 请求部分,这里的职责就是监视页面发生什么事件,出现什么状况,准备对应的参数,请求Presenter处理它 /// </summary> public partial class ListEmployeeView { protected void Page_Load( object sender, EventArgs e) { #region 准备数据,参数,UI逻辑,实现了将这些UI相关代码与真正业务逻辑隔离 ListEmployeeEventArgs args = new ListEmployeeEventArgs(); if (Request.QueryString.AllKeys.Contains( "id" )) { var id = 0; if ( int .TryParse(Request.QueryString[ "id" ], out id)) { args.ProjectId = id; args.Name = HttpUtility.UrlDecode(Request.QueryString[ "name" ]); } else { args.ProjectId = null ; args.Name = string .Empty; } } else { args.ProjectId = null ; args.Name = string .Empty; } #endregion //Presenter那边已经订阅了事件,触发事件,请求Presenter处理 ViewLoad(sender, args); } }

响应部分,实现IView中定义的响应方法.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

namespace WebAppMVP.View { /// <summary> /// 响应部分,这里对应的方法的职责非常简单--显示数据,信息等等,这里不知道Presenter,没有业务逻辑. /// </summary> public partial class ListEmployeeView { public void ShowEmployee(ListEmployeeViewModel vm) { this .rpEmployee.DataSource = vm.Employees; this .Title = string .IsNullOrEmpty(vm.ProjectName) ? "员工列表" : vm.ProjectName + "的员工列表" ; this .lbProjectName.Text = this .Title; } public void PageDataBind() { this .DataBind(); } } }

?

1	就这样,基于MVP的开发就完成了.

简单总结

1.首先发现是,有很多XXX.cs,也就是说类文件和类,接口会多好几倍.

2.功能,职责很清晰,可测试性也大大提高.

3.跟传统开发差别较大,相对有点不好理解,相信这也是很少人用的原因

4.疑问1,没有用来做过实际项目,不知道应对需求变更方面能力如何?

5.疑问2,可以看到上面基本没有提到M,基本是PV的交互,感觉MVP中的M作用相对较弱,是一个类似Domain Service的角色,小一点的系统中M完全可以不要(不过小系统也没必要用MVP了).

the end