(翻译) 是“臃肿的ViewController”还是糟糕的代码
image.png
原创作者：Besar
原文链接：https://medium.com/flawless-app-stories/massive-view-controllers-or-bad-coding-style-bf2b0d57c268
当你决定开始进入iOS开发的时候，就已经把自己置身于一个新的开发语言，新的API接口，新框架，新规范中。同样的，你需要面对新的架构设计模式，Apple的 Model，View，Controller或者说 MVC（Apple自己推荐的架构）。
在使用Apple的 MVC 之前，让我们先停下来谈一谈经典的MVC。MVC传统上被Java, Python,Ruby等主流编程语言使用，主要用于GUI程序。
MVC（Model View Controller）
image.png
就如你在上图看到的，Model 的职责是管理应用程序的数据。它是应用程序动态数据结构和架构模式的核心组件，视图层以某种格式展示Model，比如表单，图表等等。
当 Controller 校验完接收到的用户输入之后，通过将输入转换成命令给到 Model 和 View 来执行用户操作。
你可能会问是否有可能用这个架构来开发一个app？可以的，但由于很多原因你不会想真的这么做。原因就是，你不能保证我们能够使代码解耦。Model、 View、 Controller 这三个模块的实体都相互暴露给对方，因此它也不能帮助我们解决代码复用和不灵活的问题。
那么Apple的MVC呢？
image.png
Apple的 MVC 架构都是围绕3个实体通信在进行的（跟上面提及的一样），并且它们在通信必须遵守一定的规则。Controller 是这个架构下通信的核心，它的职责是为 View 层格式化 Model 的数据，为 Model 层解读用户交互的操作。由于 Model 是UI层独立的存在，MVC 架构通信中最重要的一个原则是，Model 层和 View 层不应该相互调用。
当我们把 Controller 作为MVC架构的中心的时候，View 自然而然地成为Controller的部下，View和Model不能相互通信。那么有个问题，View能否主动和Controller通信？
是的，可以。
但是，由于View不拥有它们展示的数据，所以通信必须是 黑盒 的。举个例子，collectionView和其它类为你展示了一个巨大的图书页面。假如这个书本有100k页，为每一页创建一个view是愚蠢的。因此，另一种方法是使用协议机制来调用一组预定义的方法，如 numberOfItemsInSection、cellForItem等等。这个方式要求 Controller 提供 Model 的数据并且显示它，像我们上面提到的一样。
但是 Model 呢？它能够主动和Controller通信吗？按照我们上面提及的，Model是独立与UI存在的，由于控制器本质上依赖于UI，所以通信不能是直接的。如果Model的某些数据发生了变化，而它需要更新任何UI，那么我们可以在场景中使用 Notification 和 KVO。
为了给你个更好的描述，这里有一个图，来自斯坦福大学教授 Paul Hegarty.
image.png
看起来很简单对吧？但事情会变得越来越棘手。
当我们只有一个简单的ViewController，它只是处理事件和管理页面UI布局的时候，一切都在掌控之内。除了我们上面提到的，你应该还需要做以下的事情：
- 导航到其他页面
- 网络请求
- 缓存
- 错误处理
- Model 编码/解码
好吧，在面对这些的时候，你可以把上面提到的业务都放在 ViewController 里面。过了不久之后，你就开始抱怨 MVC 就代表了 “臃肿的ViewController”。或许，可以停下抱怨，去检查哪一部分的业务不是ViewController的职责。
这些业务逻辑中哪一个是可以从ViewController中移出来的呢？
事实上，几乎上面所有的业务都可以从ViewController中移出来，让我们来举些例子。
导航（Navigation）
Push 到一个新页面没必要在ViewController中实现，作为代替，你可以使用协调模式（Coordinator Pattern）：
在iOS项目中使用协调模式 能够帮我们把导航逻辑从ViewController中移出来，能够让它们更易于管理和复用，同时让我们可以随时根据需求调整我们应用程序的流程。
布局（Layout）
另外一个可以从ViewController中移出来的业务是UI布局（Layout）。在这中情况下，你能够做的就是创建一个自定义的View，然后在loadView()方法里面，把self.view替换成我们的自定义view。
class SettingsViewController: UIViewController {
override func loadView() {
self.view = SettingsView() // custom view
}
}
网络请求 + 错误处理，编码/解码 & 缓存
创建一个用来处理网络请求的任务的分离的类，比起在ViewController中处理是一个更好的方式，就如你在下面代码看到的：
class ApiService {
static let shared = ApiService()
fileprivate func fetchData<T: Decodable>(urlString: String, completion: @escaping (T) -> ()) {
let url = URL(string: urlString)
URLSession.shared.dataTask(with: url!) { (data, response, error) in
if let error = error {
print("Failed to fetch data:", error)
return
}
guard let data = data else { return }
do {
let obj = try JSONDecoder().decode(T.self, from: data)
completion(obj)
} catch let jsonError {
print("Failed to decode json:", jsonError)
}
}.resume()
}
}
class ViewController: UIViewController {
fileprivate func loadData() {
ApiService.shared.fetchData(urlString: "https://url.com/api/v1/books") { (books: [Book]) in
books.forEach({print($0.title)})
}
}
ViewController调用 ApiService 类中有完成回调的fetchData方法，更棒的是你也可以在这个类里面进行错误处理，编码/解码或者缓存。这个方式可以避免出现 “臃肿ViewController” 的情况。
结论
无论如何，我不会将一个架构设计模式置于另一个之上。这篇文章的目的是澄清一些关于 MVC 的误解，有些开发者打算把所有的逻辑都放在 ViewController上，这是你在Apple的文档中找不到的建议。
架构不是用来解决我们的问题，而是帮助我们解决问题。每种设计模式体系结构都有其优点和缺点，并且每种模式都注定要处理特定的情况，所以要明智地使用它们。
