详解MVP模式的十四条清规戒律
.NET程序设计不光是对于Visual Studio 2010这样的工具使用上，或者一些小技巧。还包括一些设计理念和设计规则，这些反而是促进程序员进步的源泉。
之前写了一篇名称为《谈谈关于MVP模式中V-P交互问题》的文章，主要表达本人对于MVP模式下（主要针对Passive View变体）View和Presenter之间的关系，以及它们之间的交互应该采用怎样的原则和方式的看法。园子里的朋友对此展开了一些讨论，尤其是是一个叫做非空的朋友转述了另一篇文章提出的关于CAB中关于MVP模式的14条规则，和本人的观点有很多相似之处，当然也有一些不一致的地方。为此，在本篇文章中，就此进行一些必要的补充。
一、CAB（Componsable Application Block）基于14条MVP规则
为了让所有的人都能够阅读上面提及的那篇文章，我将其转载我个人的博客中，有兴趣的读者可以仔细阅读（《Design Rules for Model-View-Presenter》）。文章作者提出的观点和我在《谈谈关于MVP模式中V-P交互问题》中的观点是一致的，即Presenter对于View应该是相对透明的，View不能直接对Presenter进行操作，目的是实现Presenter和View之间的分离（The generated code is not quite as I would like it, I prefer that the view has no knowledge of the presenter and no direct access to it either as this gives a cleaner separation between views and presenters）。文章作者倾向采用事件注册的方式实现Presenter和View，不过我不太清楚具体是注册View还是Presenter的时间。在《谈谈关于MVP模式中V-P交互问题》中对MVP的实现手段，我采用的是在Presenter注册View的事件。关于View和Presenter的分离，我的做法作得更加彻底一点——根本就不给开发者从View调用Presenter的机会。
文中提出了关于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的业务逻辑，这样可以使你的代码具有自表述性并更加易于理解。
再次回到《谈谈关于MVP模式中V-P交互问题》中讨论的话题，在我看来，抛开1和2对View的Presenter命名的规范外，其余的12条规则体现了MVP关于View和Presenter之间应该具有的关系，以及我们应该采取的正确的Presenter和View交互方式。View和Presenter之间的关系，可以通过对Presenter的角色界定来体现，在整个MVP体系中Presenter扮演的是协调者的角色。
二、Presenter是协调者，是整个MVP体系的控制中心
如果我们将MVP体系比喻成一个社团（考虑到中国没有黑社会，这里我们说社团），我们经常看见的往往是那些在外面接待的人，你可以将它们看成是View。也就是说View是和外界打交道的人，是行动者，就像是到处砍人、收保护费，以及和别的社团抢地盘的都是这些处于社团基层的小混混一样。View永远处于处于幕前，和最终用户进行交互，但是地位却不高。对于用户的UI交互请求该如何进行处理，View做不了主，它需要向大佬汇报。所以View永远不可能是决策者，仅仅是一个汇报者而已。
Presenter才是真正的大佬、话事人，执龙头杖的。Presenter生藏不露，最终用户感知不但它的存在，就像社团大哥大都隐藏的比较好，甚至以政府官员（比如文强大哥）或者是电影公司老板（比如香港的XXX电影公司）的身份出现。但是，我们知道，他才是整个社团的主导、核心，是整个事务的决策者和执行者，使能够调动相关资源的协调者，而这个事务，你可以理解为Use Case。也就是说，Presenter是对Use Case的反映，UI交互逻辑的处理流程定义在Presenter中，但是具体的实现并不是完全在Presenter中，这一点很重要，下面一节中我们还会谈到。
我们还是把话题回到交互上面。这里的交互，即View和Presenter之间如果沟通，是比较特别的。谈到沟通，很多人都会认为这是一个双向的问题，而View和Presenter采用单向的沟通方式，这和某些上下级的沟通方式有点类似——下级单方地向上级汇报工作，上级单方的向下级下达命名。这在等级观念深重社团中更是如此，我们习惯的场景是这样的：小混混向大佬说：“我们的场子昨天晚上被砸了，怀疑是XXX干的”。大佬说：“恩，知道了，下去吧！”。真正有前途的小混混不会说“我们的场子昨天晚上被砸了，怀疑是XXX干的，我们什么时候去砍他？”。真正有范儿的大佬不会马上命令你在什么时候、什么地点、带多少兄弟去砍人，而在计划实施的时候会向相关成员下达砍人的指令。
反映在真正View|Presenter的交互上面，就是说：View单纯地将用户的交互请求汇报给Presenter；Presenter接收到请求之后，整合相应的资源、执行相应的处理逻辑。对处理流程的某一个步骤，如果设置到业务逻辑和数据模型，则调用Model，如果涉及到对GUI控件的操作，还会调用View。View将交互请求递交给Presenter之后，不需要考虑后续需要做什么，因为Presenter会在适当的时候命令View该如何做。
所以说，Presenter是整个体系的驱动着，View和Presenter不应该是一种拉的关系，而是一种推的关系。View将用户交互请求推给Presenter，Presenter将数据推给View并驱动View完成相应的UI相应。 正因为如此，上面的MVP规则列表中才规定Presenter的方法不需要返回值，View的接口不需要定义属性。实际在我个人看来，Presenter和View接口都应该只包含返回类型为void的方法即可。
三、Presenter不关注具体的实现细节
谈到这里有人会说，所有的关于UI处理逻辑定义在Presenter中，那么会不会使Presenter变得臃肿不堪呢？持这种观点的人实际上走入了另外一个误区。我曾经看到过有人写过这样一个极端的例子——将View的所有控件都以属性的方式公布出来，定义在View接口中，所有控件相关的操作都实现在Presenter中。很明显这是不对的，虽然这个例子很极端，但是我想很多对MVP不是太了解的人或多或少会犯这种错误。
在上面一节中，我们说过UI交互逻辑的处理流程定义在Presenter中，但是具体的实现并不是完全在Presenter中。Presenter是蓝图的设计者，并不关注实现的细节。大佬只是制定行动计划，真正砍人、收保护费和抢地盘这种操作性强的工种的还是属于小混混们。
所以该View干的事一件也逃不了，只是View不考虑什么时候干，因为Presenter会在适当的时候通知你，View得保证随叫随到。为了保证Presenter能够有效地控制View，需要将这些操作定义在接口中。既然定义在接口中，操作的粒度就不能太细。Presenter关于的是整个Use Case的处理流程，所以定义在View接口中的操作也应该采用处理流程相关的语言来定义。