在差不多两年的时间内，我们项目组几十来号人都扑在一个项目上面。这是一个基于微软SCSF（Smart Client Software Factory）的项目，客户端是墨尔本一家事业单位。前两周，我奉命负责对某个模块进 行Code Review工作，在此期间，发现了一些问题，也有了一些想法。不过，有些想法可能还不是很成熟 ，不能完全保证其正确性，有机会写出来讨论一下。今天来说说关于MVP的一些想法。
一、简单讲讲MVP是什么玩意儿
如果从层次关系来讲，MVP属于Presentation层的设计模式。对于一个UI模块来说，它的所有功能被分 割为三个部分，分别通过Model、 View和Presenter来承载。Model、View和Presenter相互协作，完成对 最初数据的呈现和对用户操作的响应，它们具有各自的职责划分。Model可以看成是模块的业务逻辑和数 据的提供者；View专门负责数据可视化的呈现，和用户交互事件的相对应。一般地，View会实现一个相应 的接口；Presenter是一般充当Model和View的纽带。
MVP具有很多的变体，其中最为常用的一种变体成为Passive View（被动视图）。对于Passive View， Model、View和Presenter之间的关系如下图所示。View和Modell之间不能直接交互，View通过Presenter 与 Model打交道。Presenter接受View的UI请求，完成简单的UI处理逻辑，并调用Model进行业务处理，并 调用View将相应的结果反映出来。View直接依赖Presenter，但是Presenter间接依赖View，它直接依赖的 是View实现的接口。关于MVP和Passive View基本的常识性东西，不是本篇文章论述的重点，对此不清楚 的读者相信可以Google出很多相关的资料来，所以在这里就再多做介绍了。
二、Passive View模式的基本特征总结
Passive View，顾名思义，View是被动的。那么主动是谁呢？答案是Presenter。对于Presenter的主 动性，我个人是这么理解的：
Presenter是整个MVP体系的控制中心，而不是单纯的处理View请求的人；
View仅仅是用户交互请求的汇报者，对于响应用户交互相关的逻辑和流程，View不参与决策，真正的 决策者是Presenter；
View向Presenter发送用户交互请求应该采用这样的口吻：“我现在将用户交互请求发送给你，你看着 办，需要我的时候我会协助你”，不应该是这样：“我现在处理用户交互请求了，我知道该怎么办，但是 我需要你的支持，因为实现业务逻辑的Model只信任你”；
对于绑定到View上的数据，不应该是View从Presenter上“拉”回来的，应该是Presenter主动“推” 给View的；
View尽可能不维护数据状态，因为其本身仅仅实现单纯的、独立的UI操作；Presenter才是整个体系的 协调者，它根据处理用于交互的逻辑给View和Model安排工作。