剖析几种流行的 iOS 设计模式--MVC;MVVM;VIPE

在这篇文章里，我们争取用最精简的语言，解释清楚这几种设计模式到底给我带来了什么便利。

以看图说话的方式逐一解释，最后总结

MVC

legacy MVC

这是我们最早接触，也最熟悉的设计模式了

但要记住 Controller 不是我们通常理解的 ViewController ！Controller 你可以认为是 Helper 方法。他不掌管 View 的生命周期。也就是说和 UIKit 无关！ViewController 你可以把他理解为 Scene 或 装配中心。

感谢有人做了一个精辟的总结。看图理解吧:

MVC

这才是真正的 MVC 使用姿势。

---

MVP

MVP

从对比可以看到 MVC 的 Controller 变成了 Presenter  , UIView 或 UIViewController 为 View 层。View 持有 Presenter，Presenter 持有 Model。View 与 Model 完全隔离。

当事件发生，交由 Presenter 进行业务逻辑处理，Presenter 从 Model 拿数据，拿到数据后然后将数据返回给Presenter，Presenter 再返回给 View 。可以理解 Presenter 是一个中间人。

同样 Presenter 应完全不依赖 UIKit 。如果需要与 View 交互，可以采用 Protocol 协议进行约定，调用。保证逻辑清楚，可测试。

最简样列代码：

MVP Example

注意中文标注的地方。

另外还有一个 Supervising Presenter MVP 的升级版本，将 View 与 Model 进行绑定。View 会受到 Model 的变更影响，同时 Presenter 依旧可以控制 View 状态。这种模糊的职责关系，还是少用为好。

MVVM

MVVM

和 MVP 一样，View Model 承担了类似 Presenter 中间层的角色。区别在于"数据与用户行为"的绑定是在 View 与 View Model 层上发生的。这个时候不影响这个设计架构中 View Model 应该承担的角色属性：更新 View 状态。

关于绑定我们可以用 KVO 模式及函数式编程来实现我们的所需。如果你想更高效的完成这个动作，可以参考现有的解决方案:
  1.  KVO : RZDataBinding or the SwiftBond
  2.  Functional programming:  ReactiveCocoa, RxSwift or PromiseKit

不过，对于 ReactiveCocoa 我只能说慎用，设计起来会非常麻烦。

这里，我们还列举最简单的例子，没有用到 KVO 或 RX 之类的设计，使用最为传统的 Protocol 来实现彼此的交互过程

MVVM Example

我们可以看重点中文标注的地方，这里通过协议里的定义，第一步 View 层发起数据请求 showGreeting 交由 ViewModel 进行数据处理，处理完成后，因 greeting 发生变化，触发 greetingDidChange 事件发生。

在这个实例里 ViewController 有设定 greetingDidChange 回调，所以实现了类似了上面所说的数据与行为绑定。

VIPER

VIPER

从结构上来看，在 Presenter 中间多了一层 Interactor ，它主要起到了数据维护访问的职责。你可以封装更多的 Service 或 Managers 做为依赖调用。

对于页面间的跳转，这里增加了 Router 层，专门用于跳转逻辑，实际上现在不少架构已经加了各自的 Router 逻辑。这一点可能是从 Rails 框架继承而来。

下面的例子不包含 Router 层

VIPER Example

从以上最简的示例代码来看，View 层 (ViewController) 同样还是通过  Presenter 层 (GreetingViewEventHandler) 触发事件逻辑，只不过 Presenter 拿数据是从 Iteractor 层（GreetingProvider）去拿。层与层之间还是通过协议通导，不依赖实体。

从这个架构来看，它的耦合性是最小的，不过也带了设计上的复杂性。所以使用时，要因地制宜。

总结

最后附上一位专家 Bohdan Orlov 的总结，它们的横向对比图，寻找自己最适合的模式使用。

iOS Arch comparison

耦合度 (Distribution)
可测性 (Testability)
易用性 (Ease of use)

PS：这里也提到了 Redux 模式，想了解 Redux 相关的内容话，看这个链接吧。研究不深，大致是和 FP (函数式编程) 与 State 流相关。

总而言之

1. 没有杀手锏
    no Sliver Bullet
2. 分层治理
    分久必合，合久并分，看具体业务场景
4. 低耦合，高内聚
    基本要素
5. 遵从流行的框架与概念，有利于团队间的沟通成本
    如果一定要发明，请多推广你的概念
6. 从简到繁，再化繁为简
    前一个繁是业务的属性，后一个繁是框架本身