内容概览

• 前言
• MVVM
• MVVM-C
• 总结

前言

MVC 模式是一个非常经典且精简的设计模式，常见的 iOS 项目基本上都采用了这种模式进行开发。

然而，随着项目规模的增长，MVC 模式已经无法很好地帮助我们解耦，构建一个易维护的项目变得愈发艰难。

业务逻辑愈加复杂，导致项目的代码量剧增是最直接的原因。某个 View Controller 可能会有几千行代码，这样的项目代码易读性非常差，维护难度也会增大。而且，这也容易导致数据的读写不同步，在较为混乱的代码中维护复杂的数据流，非常容易导致盘根错节的问题。

MVVM 在 MVC 的基础上增加了 ViewModel，实现了与 MVP 相近的效果。
由于 App 开发往往涉及许多导航逻辑的处理，而这些导航逻辑如果与业务逻辑耦合在一起就会难以管理，MVVM-C 也在iOS开发社区中应运而生。

接下来，请和 Ficow 一起结合架构图来分析这两种App设计模式吧~

MVVM

MVP 需要与 View 在协议上进行耦合，为了解决这个问题，MVVM 引入了 ViewModel。
ViewModel 并不直接引用 View，View 可以通过观察 ViewModel 的变化来执行相应的操作。

通常，MVVM 基于绑定机制工作（如：ReactiveCocoa, RxSwift, Combine 等）。这样，借助类型擦除后的订阅链，数据可以从 View，发到 ViewModel，最终到达 Model。同样，Model 层的数据也可以发到 ViemModel，最终到达 View。

由于每一层依赖的是某一种事件的数据流（而非 MVVM 模式中的某种实体，如：View），MVVM 借助数据驱动，有效地实现了各部分之间的解耦。

基于 MVVM 模式开发的项目非常易于测试，只需要为 ViewModel 提供相应的输入源，然后在测试的时候订阅 ViewModel 的输出源，即可根据不同的输入数据检查对应的输出数据。

如果您想采用基于绑定的 MVVM 模式，需要注意以下事项：

• 虽然基于绑定机制的 MVVM 模式比较强大，但是上手的难度比较高。对比 MVC 和 MVP，这种模式建立在函数式编程和响应式编程的基础上，所以对于习惯于指令式编程的开发人员来说，思维上的转换有一定的难度。
• 另外，由于数据流被擦除了具体类型，而且中间可能有各种操作符进行各种数据转换（修改、合并、过滤、限流等），修复bug的工作可能会变得更难（除非，数据流是单向的）。
• 绑定代码中往往需要构建大量的闭包，如果处理不当，就会出现循环引用等内存泄露问题。

如果您感兴趣，可以参考 Ficow 的相关文章：

• RxSwift + MVVM 如何构建 ViewModel ？
• Combine + MVVM 如何构建易测试的 ViewModel？

MVVM-C

由于页面导航和视图层关系密切，ViewModel 往往涉及到视图层级的管理问题。但是，管理具体导航层级的工作不太适合由 ViewModel 来负责。ViewModel 甚至有可能需要支持跨平台特性，比如同时支持 iOS, macOS, watchOS 等。然而，这一部分工作如果放在 ViewController 中，又会导致这部分代码的逻辑难以测试。

于是，有牛人在 iOS 社区里提出了 Coordinator 模式。实质上，这就是 ViewController 的路由器，专门负责管理 push, pop, present, dismiss 这些导航层级的工作。

基于这样的模式，ViewModel 会将与导航相关的事件发送给 Coordinator，Coordinator 会根据内部的导航逻辑来决定启动哪一个 Coordinator，然后后续的导航工作会由刚刚被启动的 Coordinator 来完成。

对于导航逻辑较为复杂的项目来说，引入 Coordinator 可以有效地帮助 ViewModel 剥离导航逻辑，从而简化 ViewModel 的职责。

具体的实现代码其实比较简单，您可以参考这篇文章：

How to use the coordinator pattern in iOS apps

总结

无论是 MVP 还是 MVVM，我们都不能盲目追随，一定要根据项目的规模和复杂度来选择适合自己的模式。

技术是服务于需求的，如果需求很简单，MVC 也可能是最好的选择呢~

参考内容：
App 架构 - objc.io
The Clean Architecture
ios-clean-architecture
ios-architecture
How to use the coordinator pattern in iOS apps