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递交用户交互请求，仅此而已
