剖析几种流行的 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. 从简到繁，再化繁为简
前一个繁是业务的属性，后一个繁是框架本身
