读『 iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER 』

[ShannonChenCHN]

读『 iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER 』

• 完整的项目示例代码
• MVC 的示例代码
• MVP 的示例代码
• MVVM 的示例代码
• VIPER 的示例代码

一、引言

当我们面对架构时经常会遇到这样一些问题：

• iOS 开发中 MVC 用的不愉快？
• 对 MVVM 的应用心存疑虑？
• 听说过 VIPER，但是不确定是否值得一试？

上面提到的都是些方向性的问题，也许你还有些其他更急切、更实际的问题要解决：

• 网络请求应该由谁发起：Model 层，还是 Controller 层？
• 怎样把一个 model 传给一个 view 的 view model？
• 谁来负责创建一个新的 VIPER 模块：Router，还是 Presenter？

二、为什么要架构选型

1. 为什么要架构选型

因为如果你不考虑架构的话，很有可能就会面临这样一个问题，在一个包含各种逻辑的庞大的类中查找问题、进行调试，你会发现你根本就没法搞清楚这个类到底是干什么的，也难以把这个类当成一个独立的实体看待。实际情况很有可能是这样的：

• 这个类就是 UIViewController 子类
• 你的数据存储逻辑都是直接在 UIViewController 中处理的
• UIView 相关的类基本上什么都没干，除了 UI 展示
• 你的 Model 仅仅只是一个数据结构
• 单元测试覆盖率非常低

让人感到困扰的是，Apple 的 MVC 并不能解决上面的这些问题。

2. 好的架构应该是什么样的

• 职责划分（Distribution）：对各实体（entity）进行了均衡的职责划分，而且每个实体扮演着明确的角色

  减低复杂度最简单的办法就是拆分（也许你听过分治法的算法思想），所以在架构上我们可以遵循单一功能原则，把各种职能拆分给不同的实体。

• 可测性（Testability）：往往是受第一个条件的影响，其实只要架构设计合理，做好这点并不难

  添加新功能或者重构都有可能会产生 bug，通过测试我们可以提高程序的稳定性，以避免等到用户手机上使用时才发 bug。

• 可用性（Ease of use）：易于使用和维护

  写的代码越少，bug 就越少。所以呢，易用性的一个方面就是可以少写代码，另一个方面就可维护性——易于理解（聪明的解决方案可能并不好理解，所以如果能尽量简单）

三、MV(X)

1. MV(X)

现在我们常见的几种架构设计模式有：

• MVC
• MVP
• MVVM
• VIPER （读者注：这里没提到 MVCS）

前三种架构模式的一个共同点，就是把各个实体分为 3 类：

• Models：跟数据相关的层，包括作为数据结构的 model，以及处理数据的逻辑。比如 Person 或者 PersonDataProvider 这样的类
• Views：负责 UI 展示，在 iOS 中一般就是以 UI 开头的那些类
• Controller/Presenter/ViewModel ：作为 view 和 model 之间的桥梁，当 model 数据发生改变时，反馈变化到 view 的展示上，当响应用户在 view 层的交互操作时，同步修改 model 层的数据。 （读者注：处理数据的实体也能叫 model 层吗？viewController 算不算 view 层？）

这样划分的好处显而易见：

• 易于理解
• 易于复用（主要是 view 和 model）
• 方便独立测试

2. MVC

2.1 标准的 MVC

• View 是无界限的，当 model 发生改变时，controller 就会重新渲染 View，就像点击网页上的链接时 reload 的过程一样
• 尽管可以在 iOS 上应用，但是并没有什么意义
  • M、V 和 C 层都紧密地耦合在了一起，任何一方都知道另外两方
  • 复用性差

Traditional MVC doesn't seems to be applicable to modern iOS development.

2.2 Apple 的 MVC

理想

Controller 作为 View 和 Model 之间的中间者，这样 View 和 Model 就不需要知道对方了

• 优点：View 和 Model 易于复用
• 问题：但是由于繁杂的业务逻辑都转移到了 Controller 中，所以 Controller 就变得复杂了

现实

（图中的虚线代表什么？Model 和 Controller 之间的 notify 代表什么）

• 根源：正是 Cocoa MVC 促使你们写成了 Massive View Controller，因为 ViewController 管理着 View 的生命周期。

• 问题：虽然有些逻辑可以转移到 Model 层，但是 View 层相关的逻辑就无能为力了，View 一般会把事件交给 Controller 处理

• 现状：Controller 负责的任务就多了，实现 delegate 和 data source 方法，负责网络请求相关的逻辑，上下拉刷新……

• 向现实妥协的 MVC：

  • 为了减轻 Controller 的负担，我们有时候会像下面这样，直接将 model 传给 view，这样就违背了 MVC 的初衷了
  • 严格的 MVC 下，我们应该只能在 Controller 中去设置 Cell（View） 的展示，而不是把 Model 扔给它，但是这样会增加 Controller 的负担😂

    var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
    userCell.configureWithUser(user)

  Cocoa MVC is reasonably unabbreviated as the Massive View Controller.

  MVC assembling can be performed in the presenting view controller（怎么理解？）

• 单元测试：View 和 Controller 之间的通信不适合测试

The interactions between the View and the Controller aren’t really testable with Unit Tests

回顾：对于小项目来说，也许你不需要考虑太多的架构问题，而且你也不希望有较高的维护成本，那么 Cocoa MVC 正好合适

• 职责划分（Distribution）：View 和 Model 是解耦的，但是 View 和 Controller 却耦合到了一起
• 可测性（Testability）：由于职责划分不够清晰，也就有 Model 可以测试了
• 可用性（Ease of use）：与其他几种模式相比代码量最少，而且易于上手，广为人知

Cocoa MVC is the best architectural pattern in terms of the speed of the development.

3. MVP

3.1 MVP 与 MVC 的比较：

MVP 和 MVC 最大的不同在于，MVC 的 View 和 Controller 严重耦合，而 MVP 的中间者 Presenter 跟 view controller 的生命周期没有半点关系，Presenter 中也没有 view 布局相关的代码，Presenter 只负责根据数据变化更新 View，以及处理 View 的事件

What if I told you, the UIViewController is the View.

3.2 MVP 的特点：

• 职责划分（Distribution）：我们将 Controller（其实就是 View）中大部分任务划分到了 Presenter 和 Model ，而 View 的功能较少，职责更清晰
• 可测性（Testability）：view controller 是 view 而不是 Presenter，View 仅仅负责 UI 展示，所以更易于测试
• 可用性（Ease of use）：但是因为需要写很多胶水代码，进行数据和事件绑定，所以开发速度相对会慢些

3.3 MVP 的问题（Router）：

• MVP 是第一个引出组合问题的架构模式，因为它有三个分别独立的层，而我们不想让 View 知道 Model，所以在当前的 View Controller（其实也就是 View）中进行组合肯定不是我们想要的，那么我们就只能在别的地方进行组合了
• 我们可以单独设计一个 App 全局的 Router 模块，专门用来负责组装 MVP，以及进行页面之间的切换
• 这个问题不仅仅是 MVP 中才有的，后面提到的几种架构模式也会有同样的问题

MVP in iOS means superb testability and a lot of code.

3.4 MVP 的变种：绑定和信号

• 在 MVP 的基础理念上，将 View 和 Model 进行绑定，Presenter 仍然来管理来自 View 的动作事件，同时负责更新 View
• 跟传统的 MVC 一样，这种模式的职责划分不清晰，不值得提倡使用

4. MVVM：MV(X) 家族中最伟大的新生儿

4.1 MVVM 与 MVP 的比较

• 相同点：
  • 分成三个角色 Model、View、Mediator（在 MVP 中是 Presenter，在 MVVM 中也就是 View Model），各角色职责分明
  • View Controller 就是 View
  • View 和 Model 之间没有耦合
• 不同点：
  • MVVM 中使用了数据绑定，跟上面提到的 Supervising MVP 有点相似，但是不像 Supervising MVP 那样将 View 和 Model 层绑定到一起，MVVM 是将 View 和 View Model 绑定到了一起

4.2 View Model 是什么

• View Model 就是 View 及其状态的描述，但是一般跟 UIKit 没有关系
• View Model 负责更新 Model，并且在 Model 更新后会同步更新它自己，因为我们将 View 和 View Model 进行了绑定，所以 View 也会跟着 View Model 进行更新

4.3 绑定

• OS X 开发中，Cocoa 提供了绑定机制，但是 iOS 开发中没有。虽然我们可以通过 KVO 和 NSNotification 来实现响应，但还是不如绑定来得方便
• 现有方案：
  • 基于 KVO 实现的绑定工具：RZDataBinding 、 ReactiveKit/Bond
  • 完全的函数响应式编程框架：[ReactiveCocoa]()、[RxSwift]()、[PromiseKit]()

4.4 MVVM 的特点

• 职责划分（Distribution）：跟 MVP 类似，Model、View、View Model 各司其职，但是 MVVM 的 View 比 MVP 的 View 要多做一些事，因为 MVVM 中需要在 View 中是通过绑定 View Model 来实现更新，而 MVP 中 View 只需要把事件传递给 Presenter 来处理，由 Presenter 来更新 View
• 可测性（Testability）：View Model 不知道 View，所以 ViewModel 测试起来很简单。View 也可以测试，但是由于它依赖于 UIKit，所以我们一般会跳过。
• 可用性（Ease of use）：因为有了绑定机制，所以相比 MVP，使用 MVVM 实现同样的功能可以少些很多胶水代码。另外，同样由于绑定，我们在调试时会更有难度。如果采用了函数响应式编程的思想，在学习成本上也会增加。

The MVVM is very attractive, since it combines benefits of the aforementioned approaches, and, in addition, it doesn’t require extra code for the View updates due to the bindings on the View side. Nevertheless, testability is still on a good level.

5. VIPER

5.1 职能划分

• Enity：实际上就是纯粹作为数据结构的 Model
• View：进行 UI 展示，有可能是 UIView 的子类，也有可能是 UIViewController 的子类。主要负责：
  • 传递事件给 Presenter
  • 提供接口给 Presenter 进行 View 的更新
• Presenter：包含 UI 相关的业务逻辑（但是跟 UIKit 没有关系），主要负责：
  • 接收来自 View 的事件
  • 更新 View
  • 通知 Interactor 更新数据
  • 接收 Interactor 的数据更新反馈
  • 通知 Router 进行页面跳转
• Interactor：包括数据相关和网络请求的业务逻辑，例如创建一个实体（数据），或者从服务器中获取一些数据。一般会在内部调用 Service 和 Manager 来完成这里具体逻辑。主要负责：
  • 管理 Enity
  • 提供接口给 Presenter 进行数据更新
  • 数据更新后通知 Presenter
• Router：负责页面跳转

5.2 VIPER 与 MV(X) 相比有什么不同

• Model 相关的逻辑都交给 Interactor 来处理了，Entity 仅仅只是一个数据结构
• VIPER 中 Presenter 只包含 Controller/Presenter/ViewModel 中 UI 相关的业务逻辑，不包含更新数据的逻辑
• VIPER 是第一个明确地处理了导航(navigation)职责的架构模式，VIPER 中的 Router 就是针对这个问题的解决方案

Proper way of doing routing is a challenge for the iOS applications, the MV(X) patterns simply don’t address this issue.

5.3 VIPER 的特点

• 职责划分（Distribution）：毫无疑问，VIPER 的划分粒度最细
• 可测性（Testability）：better distribution, better testability
• 可用性（Ease of use）：正因为上面两点的突出，从而也导致了使用成本的上升。随着角色的增多，我们会有更多的类，我们需要在不同的类之间写更多的胶水代码用于通信

四、结论

• 没有银弹，选择架构是一个根据实际情况具体分析利弊的过程。
• 在同一个应用中可能包含着多种架构，架构是在不断演进的。
• 比如，你开始的时候使用 MVC，然后突然意识到一个页面在 MVC 模式下的变得越来越难以维护，然后就切换到 MVVM 架构，但是仅仅针对这一个页面。并没有必要对那些 MVC 模式下运转良好的页面进行重构，因为两种架构是可以并存的。

Make everything as simple as possible, but not simpler  — Albert Einstein