> For the complete documentation index, see [llms.txt](https://www.doruby.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.doruby.com/mobile/modularization/pou-xi-ji-zhong-liu-hang-de-ios-she-ji-mo-shi-mvcmvvmviper.md).

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

*--* [*原文*](https://www.jianshu.com/p/569a66182dae)*首发在简书，现移值过来。*

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

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

![](/files/-M4nW4FdNYePd0JkDkBx)

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

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

感谢有人做了一个[精辟的总结](https://www.jianshu.com/p/eedbc820d40a#)。看图理解吧:

![](/files/-M4nW9keLecHqfZila39)

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

#### **MVP**

![](/files/-M4nWEHOPDrKgsE3ak_F)

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

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

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

**最简样列代码：**

![](/files/-M4nWHizj1SQvhcZ1Loo)

 

注意中文标注的地方。

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

#### MVVM

![](/files/-M4nWMTAYKEs2OuOQiCm)

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

关于绑定我们可以用 KVO 模式及函数式编程来实现我们的所需。如果你想更高效的完成这个动作，可以参考现有的解决方案:

1. KVO: [RZDataBinding](https://link.jianshu.com/?t=https://github.com/Raizlabs/RZDataBinding) or the [SwiftBond](https://link.jianshu.com/?t=https://github.com/SwiftBond/Bond) 
2. Functional programming: [ReactiveCocoa](https://link.jianshu.com/?t=https://github.com/ReactiveCocoa/ReactiveCocoa), [RxSwift](https://link.jianshu.com/?t=https://github.com/ReactiveX/RxSwift/) or [PromiseKit](https://link.jianshu.com/?t=https://github.com/mxcl/PromiseKit)

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

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

![](/files/-M4nWPcXmMhD8WoNQ_vn)

 

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

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

#### VIPER

![](/files/-M4nWTtVHaLi6Q482g1_)

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

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

下面的例子不包含 Router 层

![](/files/-M4nWWr7iq0CWXWZK6Ad)

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

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

### 总结 

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

 

![](/files/-M4nWaQWjQ3sKEFwxibV)

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

PS：这里也提到了 Redux 模式，想了解 Redux 相关的内容话，看这个[链接](https://link.jianshu.com/?t=http://www.ctolib.com/ReSwift.html)吧。研究不深，大致是和 FP (函数式编程) 与 State 流相关。

### **总而言之** 

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