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

Arch, iOS, MVP, MVVM, VIPER

-- 原文首发在简书,现移值过来。

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

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

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

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

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

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

MVP

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

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

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

最简样列代码:

注意中文标注的地方。

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

MVVM

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

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

  1. Functional programming: ReactiveCocoa, RxSwift or PromiseKit

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

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

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

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

VIPER

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

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

下面的例子不包含 Router 层

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

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

总结

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

  • 耦合度 (Distribution)

  • 可测性 (Testability)

  • 易用性 (Ease of use)

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

总而言之

  1. 没有杀手锏 no Silver Bullet

  2. 分层治理 分久必合,合久并分,看具体业务场景

  3. 低耦合,高内聚 基本要素

  4. 遵从流行的框架与概念,有利于团队间的沟通成本 如果一定要发明,请多推广你的概念

  5. 从简到繁,再化繁为简 前一个繁是业务的属性,后一个繁是框架本身

Last updated