2017-08-19rickytang0Cocoa开发者社区

MVC

全称是 Model View Controller，是模型 (model)－视图 (view)－控制器 (controller) 的缩写。它表示的是一种常见的客户端软件开发框架。

现在，MVC 已经成为主流的客户端编程框架，在 iOS 开发中，系统为我们实现好了公共的视图类：UIView，和控制器类：UIViewController。大多数时候，我们都需要继承这些类来实现我们的程序逻辑，因此，我们几乎逃避不开 MVC 这种设计模式。

但是，几十年过去了，我们对于 MVC 这种设计模式真的用得好吗？其实不是的，MVC 这种分层方式虽然清楚，但是如果使用不当，很可能让大量代码都集中在 Controller 之中，让 MVC 模式变成了 Massive View Controller 模式。

Controller 的臃肿问题何解？

我们来看看 MVC 这种架构的特点。其实设计模式很多时候是为了Don't repeat yourself原则来做的，该原则要求能够复用的代码要尽量复用，来保证重用。在 MVC 这种设计模式中，我们发现 View 和 Model 都是符合这种原则的。

对于 View 来说，你如果抽象得好，那么一个 App 的动画效果可以很方便地移植到别的 App 上，而 Github 上也有很多 UI 控件，这些控件都是在 View 层做了很好的封装设计，使得它能够方便地开源给大家复用。

对于 Model 来说，它其实是用来存储业务的数据的，如果做得好，它也可以方便地复用。比如我当时在做有道云笔记 iPad 版的时候，我们就直接和 iOS 版复用了所有的 Model 层的代码。在创业做猿题库客户端时，iOS 和 iPad 版的 Model 层代码再次被复用上了。当然，因为和业务本身的数据意义相关，Model 层的复用大多数是在一个产品内部，不太可能像 View 层那样开源给社区。

说完 View 和 Model 了，那我们想想 Controller，Controller 有多少可以复用的？我们写完了一个 Controller 之后，可以很方便地复用它吗？结论是：非常难复用。在某些场景下，我们可能可以用addSubViewController之类的方式复用 Controller，但它的复用场景还是非常非常少的。

如果我们能够意识到 Controller 里面的代码不便于复用，我们就能知道什么代码应该写在 Controller 里面了，那就是那些不能复用的代码。在我看来，Controller 里面就只应该存放这些不能复用的代码，这些代码包括：

在初始化时，构造相应的 View 和 Model。

监听 Model 层的事件，将 Model 层的数据传递到 View 层。

监听 View 层的事件，并且将 View 层的事件转发到 Model 层。

如果 Controller 只有以上的这些代码，那么它的逻辑将非常简单，而且也会非常短。

但是，我们却很难做到这一点，因为还是有很多逻辑我们不知道写在哪里，于是就都写到了 Controller 中了，那我们接下来就看看其它逻辑应该写在哪里。

MVVM

Model-View-ViewModel 的简写。但在我的理解可以是Model-ViewModel-Controller-View

为什么要这样样理解呢？上面的问题Controller的代码处理太多东西，导致极其难复用，而且在后期调整业务，更换UI等事情上也会较为困难。

所以我的建议是将Controller的所有业务逻辑都应该移动到ViewModel层上。具体该做些什么呢？

我们可以将网络请求的借口，及返回的数据写在ViewModel里面，ViewModel再通知Controller来取得相应的数据，并显示在view上。

还可以将逻辑计算等方法封装在ViewModel里面，供Controller调用。当然如果这部分计算复用性很高，你还可以封装到其他公用的类里面。

而这个ViewModel将会是一个随时可以被其他功能模块调用的状态。而且，一个Controller可以使用一个或多个ViewModel。这样将会大大提高代码分复用性，及降低后期的维护。

MVVM 在使用当中，通常还会利用双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。而这个过程我们可以使用KVO和Notification来实现，但这样并不是最理想和高效的方式，所以我们需要结合ReactiveCocoa一起使用。

ReactiveCocoa是一个函数式编程（Functional Programming）和响应式编程（React Programming）库

函数式编程（Functional Programming），函数也变成一等公民了，可以拥有和对象同样的功能，例如当成参数传递，当作返回值等。看看 Swift 语言带来的众多函数式编程的特性，就你知道这多 Cool 了。

响应式编程（React Programming），原来我们基于事件（Event）的处理方式都弱了，现在是基于输入（在 ReactiveCocoa 里叫 Signal）的处理方式。输入还可以通过函数式编程进行各种 Combine 或 Filter，尽显各种灵活的处理。

无状态（Stateless），状态是函数的魔鬼，无状态使得函数能更好地测试。

不可修改（Immutable），数据都是不可修改的，使得软件逻辑简单，也可以更好地测试。

结合了RAC库，使得我们编写的程序更加简洁高效，维护性更高。

总结：

使用MVVM编写代码，虽然使层次增加了，但是提高了代码的复用性及提高了代码的可维护性，再结合RAC就更加牛B闪闪了。你们觉得呢？