为MVC瘦身——iOS的MVVM架构与ReactiveCocoa框架

浏览数：31 / 时间：2015年06月11日

MVC = Massive View Controller ？

有笑话称MVC为重量级的试图控制器。仔细一想，确实存在这个问题。以UITableViewController和UITableView举个例子。
一般情况下，我们没有必要创建一个自定义的tableview继承自UITableView。这意味着View的模块几乎为空白。（在相当多的时候，view也仅是一个xib文件或者一堆代码用来描述控件外观和控件的位置而已）。至于Model，十分类似于JavaBean，一个类，若干属性和constructor足矣。而大量的业务逻辑的处理被放在View Controller中。

MVC的目的与不足

最初我们希望，能够把视图、模型分离开来，并用一个视图控制器去管理两者。然而，理想很丰满，现实很骨感。实际编程时，遇到种种奇奇怪怪的情况。
例如：

涉及到网络请求放在哪里？
数据逻辑的转换放在哪里？比如把一个NSArray类型的数组转换成NSString对象并且展示出来。

要知道，视图控制器，是用来管理视图的。让它处理这些乱七八糟的逻辑，是不是显得太臃肿了，管了太多自己不应该负责的事情。
更何况，几乎所有的视图和视图控制器都是一一对应关系。既然视图离不开控制器，控制器也必须维护一个自己管理的视图，为什么不干脆把他们结合在一起？

新的设计结构——MVVM

简单来说。MVVM就是一个经过优化的MVC，这意味着它可以兼容，也本质上还是一个MVC结构。
所谓的MVVM架构，就是把那些Controller不应该负责的内容分离出来。单独作为一块。用MVVM的术语来说，就是把“将 Model 数据转换为 View 可以呈现的东西”这一可能极为复杂的过程剥离出来，放到ViewModel对象中。至于ViewController，嗯，你就负责管好你的视图吧。别的东西你也别负责了。（因此，网络请求也应该被剥离开来，放入ViewModel中，实际上一次网络请求，只不过是将一些不在本机存放的模型，从Json转换为可供View直接展示的数据）。
不管是从字面（ViewModel）还是从它的具体功能以及实现来理解，视图模型（ViewModel）依然是一个模型（Model），它为View提供了可以拿来使用的数据，也从模型（Model）提取数据并加以转化处理。

以一个简单的链状结构表示MVVM架构就是
View/ViewController ————> ViewModel ————> Model
这里ViewController对象直接持有一个ViewModel对象。ViewModel对象又直接持有Model对象。箭头不能被反向（这是MVVM架构的基本要求）。
这样导致了一个问题，ViewModel发生变化的时候怎么通知ViewController并且相应的改变View呢？这就是ReactiveCocoa框架要干的事情了。Model的变化怎么通知ViewModel呢？额。。。。。Model需要变么？额。。。一定非得要变的话，继续用ReactiveCocoa不就行了么。

ReactiveCocoa是何方神圣？

以C语言代码举个例子

    int a = 1;
    int b = 2;
    int c = a + b;
    printf("c = %d",c);

显然输出结果是“c = 3”。
如果改变一下代码，增加一行。

    int a = 1;
    int b = 2;
    int c = a + b;
    a++;
    printf("c = %d",c);

显然输出结果依然是“c = 3”。
如果我们希望c永远等于a和b的和，注意是永远等于。那么目前看来唯一的方法是每次a和b发生变化的时候重新执行c = a + b。这样的操作麻烦透了，幸运的是，iOS开发中，OC提供了KVO机制，而ReactiveCocoa框架利用了这个机制，并且进行了各种各样的拓展。