MVP 总结
最近一直在看MVP的东西,现在打算来总结一下,以便后边回顾学习
http://msdn.microsoft.com/zh-cn/magazine/ff955232.aspx
MVP 的创建者将模型(在视图中处理的数据)与视图/控制器对巧妙地分开。 他们还将控制器重命名为表示器,以强化一种概念,即在该模式中,控制器的角色就是用户与应用程序之间的调节器的角色。 表示器是向用户“呈现”UI 并接受用户所发出命令的组件。 表示器包含大多数表示逻辑,知道如何处理视图和系统的其余部分,包括后端服务和数据层。
MVP 中的一项重要创新是,视图的详细信息抽象为接口(或基类)。 表示器与视图的抽象层交互,使表示器自身成为一个可重用性和可测试性均很高的类。 这样可实现两种有意思的方案。
首先,表示逻辑独立于将要使用的 UI 技术。 因此,可在 Windows 和 Web 表示层中重用同一控制器。 最后,针对某一接口为表示器编码,该表示器可以与公开该接口的任何对象进行交互,而无论该对象是 Windows 窗体对象、ASP.NET 页面对象还是 WPF 窗口对象。
其次,同一表示器可以处理同一应用程序的不同视图。 这是关于软件即服务 (SaaS) 方案的一个重要成就,在这些方案中,应用程序托管在 Web 服务器上,并作为服务提供给每一个要求使用自定义 UI 的客户。
毫无疑问,这两项优点都不一定适用于所有情况。 这些优点是否会给您带来益处,很大程度上取决于您期望在 Windows 和 Web 前端中使用的应用程序和导航逻辑。 但是,当逻辑相同时,您可以通过 MVP 模型进行重用。
mvp的一个例子以及讲解,测试驱动开发的好例子
http://www.cnblogs.com/therock/articles/2450923.html
关于mvp很好的讲解
http://www.cnblogs.com/artech/archive/2010/03/25/1696205.html
http://www.cnblogs.com/artech/archive/2010/04/12/1710681.html
CAB的14条编写符合MVP规范的规则:
1、所有的View(包括View的接口)的名称应该以View作为后缀,比如TaskView/ITaskView;
2、所有的Presenter名称应该以Presenter作为后缀,比如TaskViewPresenter;
3、Presenter完成Use Case处理逻辑,对GUI控件的处理应该在View中实现;
4、View调用Presenter的方法应该像触发事件异常,通过调用OnXxx方法的方式来实现;
5、应该尽可能地限制View对Presenter的调用,并且调用的方式限于按照“事件”的形式,比如_presenter.OnViewReady();
6、View不允许通过Presenter直接调用Model和Service,并且Presenter的方法应该是不具有返回值的;
7、Presenter必须通过View接口的方式调用View
8、除了对View接口成员的实现外,View中的其他方法不应该是public的;
9、除了CAB ModuleController 对View的加载和限制外,View只能被Presenter调用;
10、View接口方法应该基于Use Case的逻辑起一个有意义的名称,比如SetDataSource这样的方法名称是不合法的;
11、View接口的成员应该仅限于方法,不应该包含属性;
12、所有的数据应用保持在Model中
13、定义在View接口的方法不应该包含对GUI空间名称的引用(比如AddExplorerBarGroup),因为这会使Presenter知道View太多关于实现方面的细节;
14、尽量让View的方法名称反映Use Case的业务逻辑,这样可以使你的代码具有自表述性并更加易于理解。
View单纯地将用户的交互请求汇报给Presenter;Presenter接收到请求之后,整合相应的资源、执行相应的处理逻辑。对处理流程的某一个步骤,如果设置到业务逻辑和数据模型,则调用Model,如果涉及到对GUI控件的操作,还会调用View。View将交互请求递交给Presenter之后,不需要考虑后续需要做什么,因为Presenter会在适当的时候命令View该如何做。
UI交互逻辑的处理流程定义在Presenter中,但是具体的实现并不是完全在Presenter中
杜绝开发人员将程序写成基于Proxy的MVP,在我看来,唯一的办法就是尽量弱化(不可能剔除)View对Presenter的依赖。实际上,对于MVP来说,View仅仅向Presenter递交用户交互请求,仅此而已