DO RUBY
Search…
剖析几种流行的 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. 1.
  2. 2.
    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. 1.
    没有杀手锏 no Silver Bullet
  2. 2.
    分层治理 分久必合,合久并分,看具体业务场景
  3. 3.
    低耦合,高内聚 基本要素
  4. 4.
    遵从流行的框架与概念,有利于团队间的沟通成本 如果一定要发明,请多推广你的概念
  5. 5.
    从简到繁,再化繁为简 前一个繁是业务的属性,后一个繁是框架本身
Last modified 1yr ago
Copy link