本文翻译自《Model-View-Controller (MVC) in iOS: A Modern Approach》

要跟上 iOS 发展的脚步是一件不容易的事，很多时候开发者并没有对 MVC 引起足够的重视，然而很多问题确是由此导致的。

这篇文章会帮助你绕开 MVC 实践中常见的陷阱。你可以学习到一种更现代的方法来正确地使用 MVC 开发你的 App。

而在文章的结尾，你将会了解如何防止架构上错误给你的开发工作埋下隐患。让我们开始吧！

什么是 MVC

提示：如果你已经了解 MVC 的概念，你可以放心地跳过下面内容的开头部分，直接从 MVC 的实践开始。

MVC，顾名思义是由 Model 层、View 层和 Controller 层组成：

• Model：数据存放的地方。比如数据的持久化、数据模型对象、数据的解析以及网络请求的代码都会放在这里。
• View：用户直接交互的地方。这里的类基本都是可以复用的，这些类里没有特殊的逻辑。比如，UILabel 就是把文本展示到屏幕上，并且它很容易被重用。
• Controller：Model 和 View 的中介，比较典型的是我们会在这里使用代理模式。在理想的情况下 View 对 Controller 来说是透明的。Controller 会通过一个抽象比如协议来和 View 进行交流，就像 UITableView 通过 UITableViewDataSource 来和它的数据源进行交流一样。

当你把这些放在一起时候，它应该是这样的：

是不是很简单呢？

但是常言道：细节决定成败。只有当你真正实践 MVC 的时候才会发现事情并不是想象中那么容易。

苹果官方的 MVC 文档 对 MVC 有详细的阐述，这会让你对 MVC 有一个系统的理论了解，帮助你避免潜在的问题。

但是，仅仅有理论是远远不够，实践才是检验真理的唯一标准。

MVC 的最佳实践

虽然 MVC 的理论比较容易理解，但是在实践的过程中我们还是会遇到很多棘手的问题。让我们来着手解决这些问题吧。

View 层

当用户使用你的 App 时，他们大部分时间就是在和 View 层打交道。View 层应该是 App 中最直白的部分，因为它不包含任何业务逻辑。在代码层面，你通常可以在这一层看到：

• UIView 的子类们。从最基本的 UIView 到复杂的 UI 控件。
• 一个 UIViewController（可以论证的）。我个人认为它应该属于这一层，因为 UIViewController 和其根 UIView 以及它的生命周期（loadView, viewDidLoad) 是密不可分的。当然不是所有人都同意。
• UIViewController 的 animations 和 transitions。
• UIKit/AppKit、Core Animation 和 Core Graphics 中的部分类。

这一层的代码异味（Code smell)可能有多种表现形式，但是总的来说就是在 View 层做了和 UI 不相关的事。一个典型的代码异味就是在 UIViewController 中做网络请求。

为了赶 deadline，往 UIViewController 中扔一堆代码是一件很诱惑人的事。最好别这样做，也许这在当下能给你节省几分钟时间，但是以后，你可能会为了找一个 bug 而花费几个小时，或者当你想在另一个 view controller 中重用这段代码的时候发现这很困难。

把你的 View 层和下面的清单进行核对：

• 它是否和 Model 层进行交互？
• 它是否包含任何业务逻辑？
• 它是否做了一些和 UI 不相关的事？

如果满足上述任何一个条件，那么是时候对你的 View 层进行清理和重构了。

当然，这些规则不是铁的定律，有时候由于各种原因你不等不违背。尽管如此，对它们抱以尊重还是很有必要的。

最后，如果你把这些类写得很好，你总是可以重用它们。如果你不相信我，就看看 GitHub 上 UI 组件的数量吧。

Controller 层

Controller 层是你的 App 中最少重用的部分，因为这里面包含很多特定的逻辑。这并不奇怪，有些东西在你的 App 里有用，但是对其它 App 来说没有任何用处。

通常，在这一层中你会思考这些问题：

• 先访问持久化数据还是网络数据？
• 多久刷新一次 App？
• 页面的在不同的条件下应该如何跳转？
• 当 App 进入后台的时候，哪些需要被清理？

你应该把 Controller 层当作 App 的大脑：它决定了下一步会发生什么。你会经常测试这些类，以确保一切都是如期运行。

举个例子

现在你应该对 Controller 层有了更好的认识，让我们来看一个简单例子。

提示：如果你想了解这在 App 环境下是如何工作的，可以下载我为你准备的简单 App。

想象一下你有一个 UIViewController 的子类，它想知道参加今年 WWDC 的人员名单。为了达到这个目的，它会利用一个 controller 类。因为苹果推荐我们应该重视从一个协议开始，所以我们会这么做：

enum UIState {
    case Loading
    case Success([Attendee])
    case Failure(Error)
}
 
protocol WWDCAttendesDelegate: class {
    var state: UIState { get set}
}

我们先将 state初始化为 Loading , 然后当参加 WWDC 的人员名单加载成功（或者失败）的时候更新 state 值。

因为我们不希望在 UIViewController 中处理返回数据，所以用一个单独的对象（WWDCAttendeesUIController）来实现WWDCAttendesDelegate。这样分离的操作可以让我们对 WWDCAttendeesUIController 进行独立的测试。

下一步就是为 Controller 创建一个抽象，你可以把它注入到 UIViewController 中：

protocol WWDCAttendeesHandler: class {
 
    var delegate: WWDCAttendesDelegate? { get set }
    func fetchAttendees()
}

UIViewController 子类中的实现是像这样的：

init(attendeesHandler: WWDCAttendeesHandler) {
 
    self.attendeesHandler = attendeesHandler
    super.init(nibName: nil, bundle: nil)
}
 
override func viewDidLoad() {
    super.viewDidLoad()
 
    atteendeesUIController = WWDCAttendeesUIController(view: view, tableView: tableView)
    attendeesHandler.delegate = atteendeesUIController
 
    attendeesHandler.fetchAttendees()
}

这种实现方式是把请求的操作放在UIViewController 中，把返回数据的处理操作放在WWDCAttendeesUIController中：

extension WWDCAttendeesUIController: WWDCAttendesDelegate {
 
    func update(newState: UIState) {
 
        switch(state, newState) {
 
        case (.Loading, .Loading): loadingToLoading()
        case (.Loading, .Success(let attendees)): loadingToSuccess(attendees)
 
        default: fatalError("Not yet implemented \(state) to \(newState)")
        }
    }
 
    func loadingToLoading() {
        view.addSubview(loadingView)
        loadingView.frame = CGRect(origin: .zero, size: view.frame.size)
    }
 
    func loadingToSuccess(attendees: [Attendee]) {
        loadingView.removeFromSuperview()
        tableViewDataSource.dataSource = attendees.map(AttendeeCellController.init)
    }
}

你可以看到 WWDCAttendeesUIController是 UI 的大脑，而WWDCAttendeesController是业务逻辑的大脑。

看吧，这并不难！但是这个例子引出了一个问题：谁来创建 Controller ？
我建议将 Controller 封装成可注入的，所以 Controller 应该由你的 UIViewController 来提供。这有两个主要的好处：

• 容易测试。你可以传递任何遵循FetchNumberOfTickets协议的对象。
• Controller 层可以干净地被解耦。这有助于我们明晰层的责任，使代码更加健壮。

Model 层

Model 层并不像它看起来那样不需要解释。
正如你期望的，这一层的主要组成部分是 model 对象。在票据的例子中，我们会有根据票的结构创建 model。

除此之外，Model 层里还有以下组成：

• 网络访问代码。它们是长这样的。一般情况下，整个 app 中只有一个类负责网络访问活动。
• 数据持久化代码。你会在这里使用 Core Data 或者简单的把数据转化为 NSData 存储在磁盘上。
• 数据解析代码。所有将网络请求返回数据解析为 model 对象的工作都应该在 Model 层完成。
  其中 model 对象是领域特定（domain-specific）的，网络访问的代码是高度可复用的。

Controller 会利用 Model 层里的所有元素来定义 App 中的信息流。

MVC: Massive View Controller?

一些不注意的开发者会把不属于 UIViewController 职责的代码放到 UIViewController 里，结果就变成了我们所说的 Massive View Controller。越来越多的不相关代码比如网络请求和数据解析等，最终让 UIViewController 变得十分臃肿，导致你很难最终信息的流动。更糟糕的是你很难安全地重构，因为这部分代码很难写单元测试。

想要快速找到一个方法去处理 Massive ViewController 是很困难的，所以这往往会变成技术债。这个是 iOS 开发圈常见的问题，这也是为什么 MVC 模式有些“声名狼藉”。

但是，活人总不能被尿憋死。

作为经验法则，UIViewController 里的代码不应该超过 130 行。这似乎很难做到，但是你严格地执行，还是很容易达到的。下面的几条指导原则也许可以帮助你：

• view controller 里的所有代码应该是跟 root UIView 的行为有关。
• 它应该负责 root UIView 和 Controller 之间的沟通。比如通过 IBAction 调用 Controller 里的方法（FetchNumberOfTickets）。
• UITableDataSource、UITableViewDelegate之类的代理方法也不应该放在这里。如果放在这里，就很难去测试。
• 如果你认为 view controller 有太多的属性，可以把它拆分成多个 view controller 或者创建一个自定义的 UIView。

这些仅仅是作为参考。有时候你的 UIViewController 就是很简单，那么就没必要把它拆分的那么细。需要记住的是，每当你让 view controller 承担新职责，那么就意味着你放弃了对这段代码的测试和重用。

关于 MVVM

Model-View-ViewModel，所谓的 MVVM，是 MVC 的一个派生，概念上是相似的。它们之间最大的不同是层于层之间的交流方式，并且在 MVVM 中，Controller 被 ViewModel 所取代。

在实践中，如果配合 FRP 框架进行使用，MVVM 可以大放异彩。因为 Model 被 ViewModel 监听，ViewModel 被 View 所监听，将 FRP 范式用作信息流的管理成为了一个自然而然选择。 这可以让层于层之间相互独立，低耦合度的组件也更容易被测试。

必须要说的是：架构当然是重要的，但是正确的编程范式在提高整体的代码质量中扮演着更加重要的角色。少数情况下我们会在一个 App 中引入不同的架构或者编程范式，你可能会觉得这样做破坏了代码的统一性，但是如果符合业务需求也未尝不可。

更多

MVC 的出现已经有很多年历史了，它也会一直发展下去。我们不应该让 MVC 为开发者的使用不当而背锅。

MVC 只是一个蓝图，还有很多东西需要开发者自己去填写。你可以把 MVC 看作一个食谱，它只是指引你应该怎么做，但是还有仍然有很多东西需要你自己决定。这有利也有弊，弊的是，如果没有足够的经验，你可能会绕远路。利的是，它为你自己的设计预留了灵活的空间。

软件架构没有新旧之别，它是一颗银弹。作为开发者首要关注的是好的工程原则。

假如我能给年轻时候的自己提供关于 MVC 的建议，我会告诉他：

• 首先，要明确每个对象的职责。然后才是思考代码怎么写。
• 不要低估依赖注入。它会给你代码的重用性和可测试性带来惊喜。
• 尽可能避免在 UIViewController 中写逻辑。UIViewController 越干净，你就越容易理解它的行为。

我提供了一个小工程来展示本文讨论的 MVC 最佳实践。

如果你遵循这些原则，就能让 MVC 成为你的朋友而不是敌人。