iOS 中架构模式的浅显理解

我们开发软件中应用各种模式，主要是为了

职责划分：一个类只做一件事
易用，可维护，方便扩展
解耦，相互独立，可单独测试

各种设计模式其实都是在解决上面的问题，让我们对比看看吧。

一、如何理解MVC设计模式

在通常的定义中，MVC 是下图的结构

但是在 cocoa 体系中，苹果建议的 MVC 模式如下图所示

在斯坦福课程中，解释的 MVC 如下图所示

综合一下在 cocoa 系统中可以这么理解：

M model，存储、定义、操纵数据
V view，用户看到的UI，能够和用户交互
C controller，协调者，把 model 的数据放到 view 中展示，相应 view 的交互改变 model
特别在 cocoa 系统中
C 持有一个 model，直接操作 model；model 通过 KVO、通知等方式抛出自己改变的事件
C 通过 IBOutlet 或者直接持有一个 view，他可以直接操作这个view；view 有了交互，可以通过action target 方式以及 delegate 方式让 controller 来响应事件，但是 view 并不知道具体是哪个类对象；view 的需要的数据，可以通过 protocol 的方式，让 controller 实现这个 protocol 并且成为 view 的数据源，来提供数据给 view，view并不需要知道 controller 的具体的类对象。

最简单的例子就是 UITableviewController，他一般会持有一个 NSArray 作为 model，同时根视图就是一个 UITableView，这是 view。controller 从网络或者本地加载数据赋值给 array，然后 reload tableview。tableview 绘制时请求数据源，相应用户事件会通过delegate 发起调用。tableview 与 array 并没有直接的关系。

进一步的，如果我的页面很复杂，那么这个 MVC 是怎么处理的呢？看看斯坦福的另一张讲义：

也就是 cocoa 中，Controlelr 控制的 view 可以是属于别的 MVC 中的，最外层的 MVC 来管理这些子 MVC。所以最好不要一个 C 中对应多个 view 或者 model，而是需要拆分成多个 MVC 来。

缺点：

如果严格按照MVC模式的话，不像 view 传递 model，那么代码就会臃肿，想象往一个cell 设置用户信息，单独传一个 userModel，然后 cell 内部处理会很简洁，如果分开在controller 里面传头像、姓名、签名，就会很臃肿
view 和 controller 一般都是绑定在一起的，生命周期的控制依赖于 controller，独立测试会很不方便

二、MVP 模式

基于 MVC 的缺点和优点，既然 view 和 cocoa 中的 viewController 已经那么强的紧密耦合了，那么把这两者看成同一个东西，一起做为一个 view 。
Model 层负责数据的增删改查（网络，数据库查询，本地文件读写）。
Presenter 层只是一个中介，负责数据的转发。

上图展示的是 View 持有 Presenter，Presenter 持有 Model。所以 Presenter 不依赖于具体的 View，这个可以通过 Protocol 来实现，让 View 实现一些数据更新的协议，presenter 就可以不知道View 具体是什么就能传递数据。

优点：
每一层的任务互相独立分开了，让测试更加方便。

** 缺点：**
代码量会提升很多。

示例见参考2.参考2的复杂MVP可以简化如下图所示：

三、MVVM 模式

MVP 的 Presenter 需要主动更新 view，如果增加一个绑定机制呢，model 的改变及时反馈在 view上会不会更酷。但是这样就会让 model 和 view 关联起来，所以就出来一个 viewModel 的东西。

ViewModel 持有 Model，管理 Model 并可以把 Model 中的数据处理成 View 需要的数据。同时可以处理用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码。
View 持有 ViewModel，并且和 ViewModel 中的数据绑定，让 ViewModel 中的数据改变及时反应在 View上；并且把一些按钮事件的 target 设置给 ViewModel。

优点：

View Model 的引入配合状态流和响应式编程使得 App 的结构更加清晰，交互更加流畅。
MVVM 中的 View 责任多一点，因为要设置绑定，但也因为绑定，所以代码量更少。测试时主要是测试 View Model 和 Model 。

缺点:
因为数据的双向绑定，让BUG的定位更加困难，过大的项目也会耗费更多的内存。

四、VIPER 模式

VIPER 其实是 MVP 的一种扩展，VP不变，M变成了 Interactor 和 Entity，外加一个 Routing。Entity 就是 model 的数据结构， Interactor 就是处理 model 的类，增删改查model，Routing 就是控制视图的跳转。可以看到 viper 模式分的更细，每层的功能更明确，更容易测试。但是也更复杂，代码量也会更加庞大。

可以参考下面两个图结构图。
图一：

图二：

参考1.https://www.objc.io/issues/13-architecture/mvvm/
参考2.https://github.com/amacou/MVPExample
参考3.https://www.objc.io/issues/13-architecture/viper/