ios MV(X)系类的总结

一、先回顾先MVX系列

1、MVC图示



在某种意义上，可以说所有的通信都是单向的

(1) View 传送指令到 Controller

(2) Controller 完成业务逻辑后，要求 Model 改变状态

(3) Model 将新的数据发送到 View，用户得到反馈

2、MVP图示

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向



(1) 各部分之间的通信，都是双向的。

(2) View 与 Model 不发生联系，都通过 Presenter 传递。

(3)View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

3、MVVM图示

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。



只有 viewModel和Model通信是双向的

(1)View 与 Model 不发生联系，都通过 viewModel 传递

(2)采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel

(3) 剥离controller的逻辑层

三、关于三者的分析

前三种设计模式都把一个应用中的实体分为以下三类：

1、 Models–负责主要的数据或者操作数据的数据访问层，可以想象 Perspn 和 PersonDataProvider 类。

2、Views–负责展示层（GUI），对于iOS环境可以联想一下以 UI 开头的所有类。

3、Controller/Presenter/ViewModel–负责协调 Model 和 View，通常根据用户在View上的动作在Model上作出对应的更改，同时将更改的信息返回到View上。

将实体进行划分给我们带来了以下好处：

（1）更好的理解它们之间的关系

（2）复用（尤其是对于View和Model）

（3）独立的测试

先看下传统MVC架构：

View并没有任何界限，仅仅是简单的在Controller中呈现出Model的变化。想象一下，就像网页一样，在点击了跳转到某个其他页面的连接之后就会完全的重新加载页面。尽管在iOS平台上实现这这种MVC模式是没有任何难度的，但是它并不会为我们解决架构问题带来任何裨益。因为它本身也是，三个实体间相互都有通信，而且是紧密耦合的。这很显然会大大降低了三者的复用性，而这正是我们不愿意看到的。Cocoa的MVC模式驱使人们写出臃肿的视图控制器，因为它们经常被混杂到View的生命周期中，因此很难说View和ViewController是分离的。尽管仍可以将业务逻辑和数据转换到Model，但是大多数情况下当需要为View减负的时候我们却无能为力了，View的最大的任务就是向Controller传递用户动作事件。

MVC模式的主要特征:

(1) 任务均摊–View和Model确实是分开的，但是View和Controller却是紧密耦合的

(2) 可测试性–由于糟糕的分散性，只能对Model进行测试

(3) 易用性–与其他几种模式相比最小的代码量。熟悉的人很多，因而即使对于经验不那么丰富的开发者来讲维护起来也较为容易。

然后看下MVP模式:

MVP的协调器Presenter并没有对ViewController的生命周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。就MVP而言，UIViewController的子类实际上就是Views并不是Presenters。这点区别使得这种模式的可测试性得到了极大的提高，付出的代价是开发速度的一些降低，因为必须要做一些手动的数据和事件绑定。

MVP模式的主要特征:

(1)任务均摊–我们将最主要的任务划分到Presenter和Model，而View的功能较少（虽然上述例子中Model的任务也并不多）。

(2)可测试性–非常好，由于一个功能简单的View层，所以测试大多数业务逻辑也变得简单

（3）易用性–在我们上边不切实际的简单的例子中，代码量是MVC模式的2倍，但同时MVP的概念却非常清晰

最后看下MVVM模式:

他和MVP非常像，MVVM将ViewController视作View，在View和Model之间没有紧密的联系。除此之外，它还有像监管版本的MVP那样的绑定功能，但这个绑定不是在View和Model之间而是在View和ViewModel之间。而且，MVVM不需要像MVP一样定制协议，就可以在viewmodel轻易扩展其他的一些业务逻辑。

MVVM主要特征：

（1）任务均摊: 事实上，MVVM的View要比MVP中的View承担的责任多。因为前者通过ViewModel的设置绑定来更新状态，而后者只监听Presenter的事件但并不会对自己有什么更新。

（2）可测试性 – ViewModel不知道关于View的任何事情，这允许我们可以轻易的测试ViewModel。同时View也可以被测试，但是由于属于UIKit的范畴，对他们的测试通常会被忽略。

（3）易用性 –代码量和MVP的差不多，但是在实际开发中，我们必须把View中的事件指向Presenter并且手动的来更新View，如果使用绑定的话，MVVM代码量将会小的多。

关于自己想一些看法:

鉴于工程的MVC架构，在不改变整体架构的时候，考虑MVC和MVVM并存。因为MVVM能够兼容原有MVC。而且，MVVM具备MVP的一些优质特性。

关于MVP/MVVM的demo:

http://download.csdn.net/detail/qq_18505715/9419918