为什么要关注架构设计？
因为假如你不关心架构，那么总有一天，需要在同一个庞大的类中调试若干复杂的事情，你会发现在这样的条件下，根本不可能在这个类中快速的找到以及有效的修改任何bug.当然，把这样的一个类想象为一个整体是困难的，因此，有可能一些重要的细节总会在这个过程中会被忽略。
分析三种模式的优缺点：
MVC 即 Modal View Controller（模型 视图 控制器）. 20 世纪 80年代为编程语言 Smalltalk－80 发明的一种软件设计模式
MVC 的几个明显的特征和体现：
- 任务均摊--View和Model确实是分开的，但是View和Controller却是紧密耦合的
- 可测试性--由于糟糕的分散性，只能对Model进行测试
- 易用性--与其他几种模式相比最小的代码量。熟悉的人很多，因而即使对于经验不那么丰富的开发者来讲维护起来也较为容易。
- 如果你不想在架构选择上投入更多精力，那么Cocoa MVC无疑是最好的方案，而且你会发现一些其他维护成本较高的模式对于你所开发的小的应用是一个致命的打击。
就开发速度而言，Cocoa MVC是最好的架构选择方案。”
- View 上面显示什么东西，取决于 Model。只要 Model 数据改了，View 的显示状态会跟着更改。Control 负责初始化 Model，并将 Model 传递给 View 去解析展示。
- MVC 是一个用来组织代码的权威范式，也是构建 iOS App 的标准模式。Apple 甚至是这么说的。在 MVC 下，所有的对象被归类为一个 model，一个 view，或一个 controller。Model 持有数据，View 显示与用户交互的界面，而 View Controller 调解 Model 和 View 之间的交互。
MVC 自身存在着很多不足。
1）MVC 在现实应用中的不足：
在 MVC 模式中 view 将用户交互通知给控制器。view 的控制器通过更新 Model 来反应状态的改变。Model（通常使用 Key-Value-Observation）通知控制器来更新他们负责的 view。大多数 iOS 应用程序的代码使用这种方式来组织。
2）愈发笨重的 Controller：
在传统的 app 中模型数据一般都很简单，不涉及到复杂的业务数据逻辑处理，客户端开发受限于它自身运行的的平台终端，这一点注定使移动端不像 PC 前端那样能够处理大量的复杂的业务场景。然而随着移动平台的各种深入，我们不得不考虑这个问题。传统的 Model 数据大多来源于网络数据，拿到网络数据后客户端要做的事情就是将数据直接按照顺序画在界面上。随着业务的越来越来的深入，我们依赖的 service 服务可能在大多时间无法第一时间满足客户端需要的数据需求，移动端愈发的要自行处理一部分逻辑计算操作。这个时间一惯的做法是在控制器中处理，最终导致了控制器成了垃圾箱，越来越不可维护。
控制器 Controller 是 app 的 “胶水代码”，协调模型和视图之间的所有交互。控制器负责管理他们所拥有的视图的视图层次结构，还要响应视图的 loading、appearing、disappearing 等等，同时往往也会充满我们不愿暴露的 Model 的模型逻辑以及不愿暴露给视图的业务逻辑。这引出了第一个关于 MVC 的问题...
视图 view 通常是 UIKit 控件（component，这里根据习惯译为控件）或者编码定义的 UIKit 控件的集合。进入 .xib 或者 Storyboard 会发现一个 app、Button、Label 都是由这些可视化的和可交互的控件组成。View 不应该直接引用 Model，并且仅仅通过 IBAction 事件引用 controller。业务逻辑很明显不归入 view，视图本身没有任何业务。
厚重的 View Controller 由于大量的代码被放进 viewcontroller，导致他们变的相当臃肿。在 iOS 中有的 view controller 里绵延成千上万行代码的事并不是前所未见的。这些超重 app 的突出情况包括：厚重的 View Controller 很难维护（由于其庞大的规模）；包含几十个属性，使他们的状态难以管理；遵循许多协议（protocol），导致协议的响应代码和 controller 的逻辑代码混淆在一起。
厚重的 view controller 很难测试，不管是手动测试或是使用单元测试，因为有太多可能的状态。将代码分解成更小的多个模块通常是件好事。
3）太过于轻量级的 Model：
早期的 Model 层，其实就是如果数据有几个属性，就定义几个属性，ARC 普及以后我们在 Model 层的实现文件中基本上看不到代码（无需再手动管理释放变量，Model 既没有复杂的业务处理，也没有对象的构造，基本上 .m 文件中的代码普遍是空的）；同时与控制器的代码越来厚重形成强烈的反差，这一度让人不禁对现有的开发设计构思有所怀疑。
4）遗失的网络逻辑：
苹果使用的 MVC 的定义是这么说的：所有的对象都可以被归类为一个 Model，一个 view，或是一个控制器。就这些，那么把网络代码放哪里？和一个 API 通信的代码应该放在哪儿？
你可能试着把它放在 Model 对象里，但是也会很棘手，因为网络调用应该使用异步，这样如果一个网络请求比持有它的 Model 生命周期更长，事情将变的复杂。显然也不应该把网络代码放在 view 里，因此只剩下控制器了。这同样是个坏主意，因为这加剧了厚重控制器的问题。那么应该放在那里呢？显然 MVC 的 3 大组件根本没有适合放这些代码的地方。
5）较差的可测试性
MVC 的另一个大问题是，它不鼓励开发人员编写单元测试。由于控制器混合了视图处理逻辑和业务逻辑，分离这些成分的单元测试成了一个艰巨的任务。大多数人选择忽略这个任务，那就是不做任何测试。
上文提到了控制器可以管理视图的层次结构；控制器有一个 “view” 属性，并且可以通过 IBOutlet 访问视图的任何子视图。当有很多 outlet 时这样做不易于扩展，在某种意义上，最好不要使用子视图控制器（child view controller）来帮助管理子视图。在这里有多个模糊的标准，似乎没有人能完全达成一致。貌似无论如何，view 和对应的 controller 都紧紧的耦合在一起，总之，还是会把它们当成一个组件来对待。Apple 提供的这个组件一度以来在某种程度误导了大多初学者，初学者将所有的视图全部拖到 xib 中，连接大量的 IBoutLet 输出口属性，都是一些列问题。
MVVM:即 Modal View ViewModel（模型 视图 视图模型）。2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出
MVVM 模式 的几个明显的特征和体现
- 任务均摊 -- MVVM 的 View 要比 MVP 中的 View 承担的责任多。因为前者通过 ViewModel 的设置绑定来更新状态，而后者只监听 Presenter 的事件但并不会对自己有什么更新。
- 可测试性 -- ViewModel 不知道关于 View 的任何事情，这允许我们可以轻易的测试 ViewModel。同时 View 也可以被测试，但是由于属于 UIKit 的范畴，对他们的测试通常会被忽略。
- 易用性 -- 在实际开发中必须把 View 中的事件指向 Presenter 并且手动的来更新 View，如果使用绑定的话，MVVM 代码量将会小的多。
- MVC视图控制器太大且难以管理，这个模式提供了一个很好的代替MVC的方案，它保证了让视图控制器的轻量性。
MVP 即 Modal View Presenter（模型 视图 协调器）大概出现于2000年，是MVC模式的一个变种
John Gossman 对 MVVM 的批评主要有两点：
- ：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
- ：对于过大的项目，数据绑定需要花费更多的内存。
MVP模式下的三个特性的分析：
- 任务均摊 -- 我们将最主要的任务划分到 Presenter 和 Model，而 View 的功能较少；
- 可测试性 -- 非常好，由于一个功能简单的 View 层，所以测试大多数业务逻辑也变得简单；
- 易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却非常清晰。
