在 iOS 中使用 MVC 架构感觉很奇怪？ 迁移到MVVM架构又怀有疑虑？听说过 VIPER 又不确定是否真的值得切换？
相信你会找到以上问题的答案，如果没找到请在评论中指出。
你将要整理出你在 iOS 环境下所有关于架构模式的知识。我们将带领大家简要的回顾一些流行的架构，并且在理论和实践上对它们进行比较，通过一些小的例子深化你的认知。如果对文中提到的一些关键词有兴趣，可以点击连接去查看更详细的内容。
掌控设计模式可能会使人上瘾，所以要当心，你可能会对一些问题清晰明了，不再像阅读之前那样迷惑，比如下面这些问题：
谁应该来负责网络请求？Model 还是 Controller ？
应该怎样向一个新的页面的 ViewModel 传入一个 Model ?
谁来创建一个 VIPER 模块，是 Router 还是 Presenter ?
为什么要关注架构设计？
因为假如你不关心架构，那么总有一天，需要在同一个庞大的类中调试若干复杂的事情，你会发现在这样的条件下，根本不可能在这个类中快速的找到以及有效的修改任何bug.当然，把这样的一个类想象为一个整体是困难的，因此，有可能一些重要的细节总会在这个过程中会被忽略。如果现在的你正是处于这样一个开发环境中，很有可能具体的情况就像下面这样：
- 这个类是一个UIViewController的子类
- 数据直接在UIViewController中存储
- UIView类几乎不做任何事情
- Model 仅仅是一个数据结构
- 单元测试覆盖不了任何用例
以上这些情况仍旧会出现，即使是你遵循了Apple的指导原则并且实现了其 MVC(模式，所以，大可不必惊慌。Apple所提出的 MVC 模式存在一些问题，我们之后会详述。
在此，我们可以定义一个好的架构应该具备的特点：
- 任务均衡分摊给具有清晰角色的实体
- 可测试性通常都来自与上一条（对于一个合适的架构是非常容易）
- 易用性和低成本维护
为什么采用分布式?
采用分布式可以在我们要弄清楚一些事情的原理时保持一个均衡的负载。如果你认为你的开发工作越多，你的大脑越能习惯复杂的思维，其实这是对的。但是，不能忽略的一个事实是，这种思维能力并不是线性增长的，而且也并不能很快的到达峰值。所以，能够战胜这种复杂性的最简单的方法就是在遵循 单一功能原则 的前提下，将功能划分给不同的实体。
为什么需要易测性？
其实这条要求对于哪些习惯了单元测试的人并不是一个问题，因为在添加了新的特性或者要增加一些类的复杂性之后通常会失效。这就意味着，测试可以避免开发者在运行时才发现问题—-当应用到达用户的设备，每一次维护都需要浪费长达至少[一周](http://appreviewtimes.com)的时间才能再次分发给用户。
为什么需要易用性？
这个问题没有固定的答案，但值得一提的是，最好的代码是那些从未写过的代码。因此，代码写的越少，Bug就越少。这意味着希望写更少的代码不应该被单纯的解释为开发者的懒惰，而且也不应该因为偏爱更聪明的解决方案而忽视了它的维护开销。
MV(X）系列概要
当今我们已经有很架构设计模式方面的选择:
前三种设计模式都把一个应用中的实体分为以下三类：
- Models–负责主要的数据或者操作数据的数据访问层，可以想象 Perspn 和 PersonDataProvider 类。
- Views–负责展示层（GUI），对于iOS环境可以联想一下以 UI 开头的所有类。
- Controller/Presenter/ViewModel–负责协调 Model 和 View，通常根据用户在View上的动作在Model上作出对应的更改，同时将更改的信息返回到View上。
将实体进行划分给我们带来了以下好处：
- 更好的理解它们之间的关系
- 复用（尤其是对于View和Model）
- 独立的测试
让我们开始了解MV(X)系列，之后再返回到VIPER模式。
MVC的过去
在我们探讨Apple的MVC模式之前，我们来看下传统的MVC模式。
传统的MVC
在这里，View并没有任何界限，仅仅是简单的在Controller中呈现出Model的变化。想象一下，就像网页一样，在点击了跳转到某个其他页面的连接之后就会完全的重新加载页面。尽管在iOS平台上实现这这种MVC模式是没有任何难度的，但是它并不会为我们解决架构问题带来任何裨益。因为它本身也是，三个实体间相互都有通信，而且是紧密耦合的。这很显然会大大降低了三者的复用性，而这正是我们不愿意看到的。鉴于此我们不再给出例子。
“传统的MVC架构不适用于当下的iOS开发”
苹果推荐的MVC–愿景
Cocoa MVC
由于Controller是一个介于View 和 Model之间的协调器，所以View和Model之间没有任何直接的联系。Controller是一个最小可重用单元，这对我们来说是一个好消息，因为我们总要找一个地方来写逻辑复杂度较高的代码，而这些代码又不适合放在Model中。
理论上来讲，这种模式看起来非常直观，但你有没有感到哪里有一丝诡异？你甚至听说过，有人将MVC的缩写展开成（Massive View Controller），更有甚者，为View controller减负也成为iOS开发者面临的一个重要话题。如果苹果继承并且对MVC模式有一些进展，所有这些为什么还会发生？
苹果推荐的MVC–事实
Realistic Cocoa MVC
Cocoa的MVC模式驱使人们写出臃肿的视图控制器，因为它们经常被混杂到View的生命周期中，因此很难说View和ViewController是分离的。尽管仍可以将业务逻辑和数据转换到Model，但是大多数情况下当需要为View减负的时候我们却无能为力了，View的最大的任务就是向Controller传递用户动作事件。ViewController不再承担一切代理和数据源的职责，通常只负责一些分发和取消网络请求以及一些其他的任务，因此它的名字的由来…你懂的。
你可能会看见过很多次这样的代码：
|
1 2 |
var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell userCell.configureWithUser(user) |
这个cell,正是由View直接来调用Model，所以事实上MVC的原则已经违背了，但是这种情况是一直发生的甚至于人们不觉得这里有哪些不对。如果严格遵守MVC的话，你会把对cell的设置放在 Controller 中，不向View传递一个Model对象，这样就会大大减少Controller的体积。
“Cocoa 的MVC被写成Massive View Controller 是不无道理的。”
直到进行单元测试的时候才会发现问题越来越明显。因为你的ViewController和View是紧密耦合的，对它们进行测试就显得很艰难–你得有足够的创造性来模拟View和它们的生命周期，在以这样的方式来写View Controller的同时，业务逻辑的代码也逐渐被分散到View的布局代码中去。
我们看下一些简单的例子:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
import UIKit struct Person { // Model let firstName: String let lastName: String } class GreetingViewController : UIViewController { // View + Controller var person: Person! let showGreetingButton = UIButton() let greetingLabel = UILabel() override func viewDidLoad() { super.viewDidLoad() self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside) } func didTapButton(button: UIButton) { let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName self.greetingLabel.text = greeting } // layout code goes here } // Assembling of MVC let model = Person(firstName: "David", lastName: "Blaine") let view = GreetingViewController() view.person = model; |
“MVC可以在一个正在显示的ViewController中实现”
这段代码看起来可测试性并不强，我们可以把和greeting相关的都放到GreetingModel中然后分开测试，但是这样我们就无法通过直接调用在GreetingViewController中的UIView的方法（viewDidLoad和didTapButton方法）来测试页面的展示逻辑了，因为一旦调用则会使整个页面都变化，这对单元测试来讲并不是什么好消息。
事实上，在单独一个模拟器中（比如iPhone 4S）加载并测试UIView并不能保证在其他设备中也能正常工作，因此我建议在单元测试的Target的设置下移除”Host Application”项，并且不要在模拟器中测试你的应用。
“View和Controller的接口并不适合单元测试。”
以上所述，似乎Cocoa MVC 看起来是一个相当差的架构方案。我们来重新评估一下文章开头我们提出的MVC一系列的特征:
- 任务均摊–View和Model确实是分开的，但是View和Controller却是紧密耦合的
- 可测试性–由于糟糕的分散性，只能对Model进行测试
- 易用性–与其他几种模式相比最小的代码量。熟悉的人很多，因而即使对于经验不那么丰富的开发者来讲维护起来也较为容易。
如果你不想在架构选择上投入更多精力，那么Cocoa MVC无疑是最好的方案，而且你会发现一些其他维护成本较高的模式对于你所开发的小的应用是一个致命的打击。
“就开发速度而言，Cocoa MVC是最好的架构选择方案。”
MVP 实现了Cocoa的MVC的愿景
Passive View variant of MVP
这看起来不正是苹果所提出的MVC方案吗？确实是的，这种模式的名字叫做MVC，但是，这就是说苹果的MVC实际上就是MVP了？不，并不是这样的。如果你仔细回忆一下，View是和Controller紧密耦合的，但是MVP的协调器Presenter并没有对ViewController的生命周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。
“假如告诉你UIViewController就是View呢？”
就MVP而言，UIViewController的子类实际上就是Views并不是Presenters。这点区别使得这种模式的可测试性得到了极大的提高，付出的代价是开发速度的一些降低，因为必须要做一些手动的数据和事件绑定，从下例中可以看出：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
import UIKit struct Person { // Model let firstName: String let lastName: String Ȱ以上问题的答案，如果没找到请在评论中指出。
你将要整理出你在 iOS 环境下所有关于架构模式的知识。我们将带领大家简要的回顾一些流行的架构，并且在理论和实践上对它们进行比较，通过一些小的例子深化你的认知。如果对文中提到的一些关键词有兴趣，可以点击连接去查看更详细的内容。 掌控设计模式可能会使人上瘾，所以要当心，你可能会对一些问题清晰明了，不再像阅读之前那样迷惑，比如下面这些问题： 谁应该来负责网络请求？Model 还是 Controller ？ 应该怎样向一个新的页面的 ViewModel 传入一个 Model ? 谁来创建一个 VIPER 模块，是 Router 还是 Presenter ?
为什么要关注架构设计？ 因为假如你不关心架构，那么总有一天，需要在同一个庞大的类中调试若干复杂的事情，你会发现在这样的条件下，根本不可能在这个类中快速的找到以及有效的修改任何bug.当然，把这样的一个类想象为一个整体是困难的，因此，有可能一些重要的细节总会在这个过程中会被忽略。如果现在的你正是处于这样一个开发环境中，很有可能具体的情况就像下面这样：
以上这些情况仍旧会出现，即使是你遵循了Apple的指导原则并且实现了其 MVC(模式，所以，大可不必惊慌。Apple所提出的 MVC 模式存在一些问题，我们之后会详述。 在此，我们可以定义一个好的架构应该具备的特点：
为什么采用分布式? 采用分布式可以在我们要弄清楚一些事情的原理时保持一个均衡的负载。如果你认为你的开发工作越多，你的大脑越能习惯复杂的思维，其实这是对的。但是，不能忽略的一个事实是，这种思维能力并不是线性增长的，而且也并不能很快的到达峰值。所以，能够战胜这种复杂性的最简单的方法就是在遵循 单一功能原则 的前提下，将功能划分给不同的实体。 为什么需要易测性？ 其实这条要求对于哪些习惯了单元测试的人并不是一个问题，因为在添加了新的特性或者要增加一些类的复杂性之后通常会失效。这就意味着，测试可以避免开发者在运行时才发现问题—-当应用到达用户的设备，每一次维护都需要浪费长达至少[一周](http://appreviewtimes.com)的时间才能再次分发给用户。 为什么需要易用性？ 这个问题没有固定的答案，但值得一提的是，最好的代码是那些从未写过的代码。因此，代码写的越少，Bug就越少。这意味着希望写更少的代码不应该被单纯的解释为开发者的懒惰，而且也不应该因为偏爱更聪明的解决方案而忽视了它的维护开销。 MV(X）系列概要 当今我们已经有很架构设计模式方面的选择: 前三种设计模式都把一个应用中的实体分为以下三类：
将实体进行划分给我们带来了以下好处：
让我们开始了解MV(X)系列，之后再返回到VIPER模式。 MVC的过去 在我们探讨Apple的MVC模式之前，我们来看下传统的MVC模式。
传统的MVC 在这里，View并没有任何界限，仅仅是简单的在Controller中呈现出Model的变化。想象一下，就像网页一样，在点击了跳转到某个其他页面的连接之后就会完全的重新加载页面。尽管在iOS平台上实现这这种MVC模式是没有任何难度的，但是它并不会为我们解决架构问题带来任何裨益。因为它本身也是，三个实体间相互都有通信，而且是紧密耦合的。这很显然会大大降低了三者的复用性，而这正是我们不愿意看到的。鉴于此我们不再给出例子。 “传统的MVC架构不适用于当下的iOS开发” 苹果推荐的MVC–愿景
Cocoa MVC 由于Controller是一个介于View 和 Model之间的协调器，所以View和Model之间没有任何直接的联系。Controller是一个最小可重用单元，这对我们来说是一个好消息，因为我们总要找一个地方来写逻辑复杂度较高的代码，而这些代码又不适合放在Model中。 理论上来讲，这种模式看起来非常直观，但你有没有感到哪里有一丝诡异？你甚至听说过，有人将MVC的缩写展开成（Massive View Controller），更有甚者，为View controller减负也成为iOS开发者面临的一个重要话题。如果苹果继承并且对MVC模式有一些进展，所有这些为什么还会发生？ 苹果推荐的MVC–事实
Realistic Cocoa MVC Cocoa的MVC模式驱使人们写出臃肿的视图控制器，因为它们经常被混杂到View的生命周期中，因此很难说View和ViewController是分离的。尽管仍可以将业务逻辑和数据转换到Model，但是大多数情况下当需要为View减负的时候我们却无能为力了，View的最大的任务就是向Controller传递用户动作事件。ViewController不再承担一切代理和数据源的职责，通常只负责一些分发和取消网络请求以及一些其他的任务，因此它的名字的由来…你懂的。 你可能会看见过很多次这样的代码：
这个cell,正是由View直接来调用Model，所以事实上MVC的原则已经违背了，但是这种情况是一直发生的甚至于人们不觉得这里有哪些不对。如果严格遵守MVC的话，你会把对cell的设置放在 Controller 中，不向View传递一个Model对象，这样就会大大减少Controller的体积。 “Cocoa 的MVC被写成Massive View Controller 是不无道理的。” 直到进行单元测试的时候才会发现问题越来越明显。因为你的ViewController和View是紧密耦合的，对它们进行测试就显得很艰难–你得有足够的创造性来模拟View和它们的生命周期，在以这样的方式来写View Controller的同时，业务逻辑的代码也逐渐被分散到View的布局代码中去。 我们看下一些简单的例子:
“MVC可以在一个正在显示的ViewController中实现” 这段代码看起来可测试性并不强，我们可以把和greeting相关的都放到GreetingModel中然后分开测试，但是这样我们就无法通过直接调用在GreetingViewController中的UIView的方法（viewDidLoad和didTapButton方法）来测试页面的展示逻辑了，因为一旦调用则会使整个页面都变化，这对单元测试来讲并不是什么好消息。 事实上，在单独一个模拟器中（比如iPhone 4S）加载并测试UIView并不能保证在其他设备中也能正常工作，因此我建议在单元测试的Target的设置下移除”Host Application”项，并且不要在模拟器中测试你的应用。 “View和Controller的接口并不适合单元测试。” 以上所述，似乎Cocoa MVC 看起来是一个相当差的架构方案。我们来重新评估一下文章开头我们提出的MVC一系列的特征:
如果你不想在架构选择上投入更多精力，那么Cocoa MVC无疑是最好的方案，而且你会发现一些其他维护成本较高的模式对于你所开发的小的应用是一个致命的打击。 “就开发速度而言，Cocoa MVC是最好的架构选择方案。” MVP 实现了Cocoa的MVC的愿景
Passive View variant of MVP 这看起来不正是苹果所提出的MVC方案吗？确实是的，这种模式的名字叫做MVC，但是，这就是说苹果的MVC实际上就是MVP了？不，并不是这样的。如果你仔细回忆一下，View是和Controller紧密耦合的，但是MVP的协调器Presenter并没有对ViewController的生命周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。
“假如告诉你UIViewController就是View呢？” 就MVP而言，UIViewController的子类实际上就是Views并不是Presenters。这点区别使得这种模式的可测试性得到了极大的提高，付出的代价是开发速度的一些降低，因为必须要做一些手动的数据和事件绑定，从下例中可以看出：
|
