MVP模式中VP交互问题.docVIP

MVP模式中V-P交互问题 一、简单讲讲MVP是什么玩意儿 如果从层次关系來讲，MVP屈于Presentation层的设计模式。对于一个UI模块來说，它的所有功能被 分割为三个部分，分别通过Model、View和Presenter来承载。Model、View和Presenter相互协作， 完成对最初数据的呈现和对用户操作的响应，它们其有各自的职贵划分。Model可以看成是模块的业务逻 辑和数据的提供者；View专门负贵数据可视化的呈现，和用户交互事件的相对应。一般地，View会实现 一个相应的接口； Presenter是一般充当Model和View的纽带。 MVP；H有很多的变体，其中最为常用的一种变体成为Passive View （被动视图）。对于Passive View， Model、View和Presenter之IX）的关系如下图所示。View和Modell之间不能直接交互，View通过 Presenter与Model打交道。Presenter接受View的UI请求，完成简单的UI处理遐辑，并凋用Model 进行业务处理，并凋用View将相应的结果反映出來。View直接依赖Presenter，但超Presenter IhJ接 依赖View，它直接依赖的是View实现的接口。关于MVP和Passive View基木的常识性东西，不是木 篇文竞论述的熏点，对此不清楚的读杏相信可以Google出很多相关的资料来，所以在这里就再多做介绍 了。 二、Passive View模式的基本特征总结 Passive View,顾名思义，View是被动的。那么主动是谁呢？答案是Presenter。对十Presenter的主 动性，我个人是这么理解的： Presenter是整个MVP体系的控制屮心，而不是单纯的处理View请求的人； View仅仅是用户交互请求的汇报奍，对于响.应用户交互相关的逻辑和流程，View不参与决策，真 正的决策者是Presenter； View向Presenter发送用户交互请求应该采用这样的1_1吻：“我现在将用户交互请求发送给你，你 看着办，需要我的时候我会协助你”，不应该是这样：“我现在处理用户交互请求了，我知道该怎么办， 但是我需要你的支持，因为实现业务逻辑的Model只信任你”： 对子绑定到View卜.的数掘，不应该足View从Presenter卜.“拉”回來的，应该处Presenter主动“推” 给View的； View私可能不维护数据状态，因为其木身仅仅实现单纯的、独立的UI操作；Presenter汴足幣个 体系的协调者，它根据处理用子交互的逻辑给View和Model安排工作。 三、理想与现实的距离 上而对Passive View MVP特征的罗列，我觉得是一种理想状态。是在大型项M中，尤其是项目的开发者 自身并不完全理解MVP原理的惜况下，要整体实现这样的-?种理想状态是-件很难的审惜。有人可能会说, 在开发人员不了解MVP的惜况下要求他们用好MVP，你这不是扯淡吗？实际上，在这里并不是说开发人 员完全没有MVP关于关注点分离的概念，只是对MVP中的三元角色并没有非常清晰的界定（实际上也没 有-个明确的规范对Model、View和Presenter具体的职贵范围进行明确的划分），在开发的吋候，会 不自觉地受传统编程习惯的影响，将Presenter单纯地当成是View调用Model的中介。我经常这么说: 如果以View力中心，将Presenter当成是View和Model的中阆人，这也叫MVP摸式，不过这里的P 不是Presenter，而是Proxy，是Model在View的代理而已。 从Passive View中Model、View和Presenter三者之阀的依赖关系来看，这个模型充分地给了开发者 犯这样错误的机会。注意上而的图中View到Presenter的箭失农明View是可以任意的调用Presenter 的，开发人员完全有可能将大部分UI处理逻辑写在View中，而Presenter仅仅对Model响应操作的简 单调用。因为在我Review的各种所谓的MVP编程方式中，有不少是这么写的。在很多情况下，甚至不 用认？［去分析具体的代码，从View和Presenter中代码的行数就可以看出来，因为View的代码和 Presenter的代码都不在一个数竜级。 我现在的■?个H的是提出一种编程模式，杜绝开发人员将程序写成基于Proxy的MVP，在我看来，唯一 的办法就是尽量弱化（不可能剔除）View对Presenter的依赖实际上，对于MVP来说，View仅 仅向Presenter递交用户交互请求，仅此而已，如果我们将View对Presenter的这点依赖关系实现在 框架层次中，最终丌发人员的编程来说