本文，包含了关于MVC的如下内容：
一、MVC介绍
二、MVC的改进
三、MVVM简评
一、MVC的介绍
MVC，全称是 Model View Controller，是模型 (model)－视图 (view)－控制器 (controller) 的缩写。它表示的是一种常见的客户端软件开发框架。
一个UI交互的整体过程：
- View接受用户操作发送给Controller，Controller根据操作对数据进行修改；
- Controller接受数据修改的通知，并根据通知更新对应的UI。
当然Controller可能有一些自有逻辑会修改数据或者更新UI，从属关系上来说View和Model都属于Controller。
模块间的通信
1. Controller->View和Controller->Model
对Model和View的访问是一样的，在Controller的代码中，可以直接持有它们的类或者实例，进行方法和属性的访问。
2. View->Controller
- target：action：用户在view上触发事件，view会产生一个action动作，在controller中，通过addtarget:方法，接受action动作。controller自身设置target，view在需要通知controller时向controller发送action。
- delegate: controller作为view的被委托者，代理。分为：
- 动作类delegate:在controller中响应action动作。
- data source数据源类delegate：为view 提供需要显示的数据。
3. Model->Controller
如果Model希望自己的变化被Controller感知呢怎么办呢？iOS SDK提供了两种方法：
- Notification： model自己设置一个通知中心NSNotificationCenter，需要知道model数据变化的的controller自己注册一个通知addObserver来监听model的数据数据变化，让不需要监听model需要移除注册监听
- KVO： 使用addObserver:forKeyPath:option:context:方法和removeObserver:forKeyPath:方法来对model设置和移除注册监听
MVC优点：
（一）、低耦合性
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
（二）、高重用性和可适用性
视图层和model可复用。
（三）、学习成本较低，减少代码量，比较容易维护。
然而在日常开发中，我们在设置View的时候会直接来调用Model，所以事实上典型的MVC的原则已经违背了，但是这种情况是一直发生的甚至于人们不觉得这里有哪些不对。如果严格遵守MVC的话，你会把对view的设置放在Controller中，不向View传递一个Model对象，这样就会大大增加Controller的体积。
缺点：
厚重的ViewController
遗失的网络逻辑（无立足之地）
较差的可测试性
那到底我们应不应该用MVC呢？请继续往下看
二、MVC如何改进
使用MVC避免不了会造成Controller过于庞大臃肿，首先对Controller进行瘦身。
1. 对Controller瘦身
Controller 里面就只应该存放不能复用的代码，这些代码包括：
- 在初始化时，构造相应的 View 和 Model。
- 监听 Model 层的事件，将 Model 层的数据传递到 View 层。
- 监听 View 层的事件，并且将 View 层的事件转发到 Model 层。
如果 Controller 只有以上的这些代码，那么它的逻辑将非常简单，而且也会非常短。
但是，我们却很难做到这一点，因为还是有很多逻辑我们不知道写在哪里，于是就都写到了 Controller 中了，那我们接下来就看看其它逻辑应该写在哪里。
objc.io 是一个非常有名的 iOS 开发博客，它上面的第一课 《Lighter View Controllers》 上就讲了很多这样的技巧，我们先总结一下它里面的观点：
- 将 UITableView 的 Data Source 分离到另外一个类中。
- 将数据获取和转换的逻辑分别到另外一个类中。
- 将拼装控件的逻辑，分离到另外一个类中。
你想明白了吗？其实 MVC 虽然只有三层，但是它并没有限制你只能有三层。所以，我们可以将 Controller 里面过于臃肿的逻辑抽取出来，形成新的可复用模块或架构层次。
我个人对于逻辑的抽取，有以下总结。
1.1将网络请求抽象到单独的类中
这部分代码从 Controller 中剥离出来后，不但简化了 Controller 中的逻辑，也达到了网络层的代码复用的效果。
1.2将界面的拼装抽象到专门的类中
新手写代码，喜欢在 Controller 中把一个个 UILabel ，UIButton，UITextField 往 self.view 上用 addSubView 方法放。我建议大家可以用两种办法把这些代码从 Controller 中剥离。
方法一：构造专门的 UIView 的子类，来负责这些控件的拼装。这是最彻底和优雅的方式，不过稍微麻烦一些的是，你需要把这些控件的事件回调先接管，再都一一暴露回 Controller。
方法二：用一个静态的 Util 类，帮助你做 UIView 的拼装工作。这种方式稍微做得不太彻底，但是比较简单。
对于一些能复用的 UI 控件，我建议用方法一。如果项目工程比较复杂，我也建议用方法一。如果项目太紧，另外相关项目的代码量也不多，可以尝试方法二。
1.3构造 ViewModel
谁说 MVC 就不能用 ViewModel 的？MVVM 的优点我们一样可以借鉴。具体做法就是将 ViewController 给 View 传递数据这个过程，抽象成构造 ViewModel 的过程。
这样抽象之后，View 只接受 ViewModel，而 Controller 只需要传递 ViewModel 这么一行代码。而另外构造 ViewModel 的过程，我们就可以移动到另外的类中了。
在具体实践中，我建议大家专门创建构造 ViewModel 工厂类，参见 工厂模式。另外，也可以专门将数据存取都抽将到一个 Service 层，由这层来提供 ViewModel 的获取。
这样一来，Controller设置view内容的代码不仅剥离出去了，而且也将model从view中脱离出来了。
1.4专门构造存储类
刚刚说到 ViewModel 的构造可以抽奖到一个 Service 层。与此相应的，数据的存储也应该由专门的对象来做。数据存取放在专门的类中，就可以针对存取做额外的事情了。比如：对一些热点数据增加缓存、处理数据迁移相关的逻辑。
如果要做得更细，可以把存储引擎再抽象出一层。这样你就可以方便地切换存储的底层，例如从 sqlite 切换到 key-value 的存储引擎等。
小结
通过代码的抽取，我们可以将原本的 MVC 设计模式中的 ViewController 进一步拆分，构造出 网络请求层、ViewModel 层、Service 层、Storage 层等其它类，来配合 Controller 工作，从而使 Controller 更加简单，我们的 App 更容易维护。
三、 MVVM
MVVM 的历史
MVVM 是 Model-View-ViewModel 的简写。
相对于 MVC 的历史来说，MVVM 是一个相当新的架构，MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出，并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了，可见两者出现的年代差别有多大。
MVVM 在使用当中，通常还会利用双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。所以，MVVM 模式有些时候又被称作：model-view-binder 模式。
具体在 iOS 中，可以使用 KVO 或 Notification 技术达到这种效果。
MVVM 的神化
在使用中，我发现大家对于 MVVM 以及 MVVM 衍生出来的框架（比如 ReactiveCocoa）有一种「敬畏」感。这种「敬畏」感某种程度上就像对神一样，这主要表现在我没有听到大家对于 MVVM 的任何批评。
我感觉原因首先是 MVVM 并没有很大程度上普及，大家对于新技术一般都不熟，进而不敢妄加评论。另外，ReactiveCocoa 本身上手的复杂性，也让很多人感觉到这种技术很高深难懂，进而加重了大家对它的「敬畏」。
MVVM 的作用和问题
MVVM 在实际使用中，确实能够使得 Model 层和 View 层解耦，但是如果你需要实现 MVVM 中的双向绑定的话，那么通常就需要引入更多复杂的框架来实现了。
对此，MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
第二点：对于过大的项目，数据绑定需要花费更多的内存。
某种意义上来说，我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是，这个缺点同时也被很多人认为是优点。
ReactiveCocoa
函数式编程（Functional Programming）和响应式编程（React Programming）也是当前很火的两个概念，它们的结合可以很方便地实现数据的绑定。于是，在 iOS 编程中，ReactiveCocoa 横空出世了，它的概念都非常 新，包括：
函数式编程（Functional Programming），函数也变成一等公民了，可以拥有和对象同样的功能，例如当成参数传递，当作返回值等。看看 Swift 语言带来的众多函数式编程的特性，就你知道这多 Cool 了。
响应式编程（React Programming），原来我们基于事件（Event）的处理方式都弱了，现在是基于输入（在 ReactiveCocoa 里叫 Signal）的处理方式。输入还可以通过函数式编程进行各种 Combine 或 Filter，尽显各种灵活的处理。
无状态（Stateless），状态是函数的魔鬼，无状态使得函数能更好地测试。
不可修改（Immutable），数据都是不可修改的，使得软件逻辑简单，也可以更好地测试。
哇，所有这些都太 Cool 了。当我看到的时候，我都鸡冻了！
我们应该客观评价 MVVM 和 ReactiveCocoa
但是但是，我突然想到，我好象只需要一个 ViewModel 而已，我完全可以简单地做一个 ViewModel 的工厂类或 Service 类就可以了，为什么要引入这么多框架？现有的 MVC 真的有那么大的问题吗？
直到现在，ReactiveCocoa 在国内外还都是在小众领域，没有被大量接受成为主流的编程框架。不只是在 iOS 语言，在别的语言中，例如 Java 中的 RxJava 也同样没有成为主流。
我在这里，不是想说 ReactiveCocoa 不好，也不是想说 MVVM 不好，而是想让大家都能够有一个客观的认识。ReactiveCocoa 和 MVVM 不应该被神化，它是一种新颖的编程框架，能够解决旧有编程框架的一些问题，但是也会带来一些新问题，仅此而已。如果不能使好的驾驭 ReactiveCocoa，同样会造成 Controller 代码过于复杂，代码逻辑不易维护的问题。
瘦身部分参考了：被误解的 MVC 和被神化的 MVVM