内容概览

• 前言
• App 任务
• MVC
• MVP
• 总结

前言

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

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

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

MVP 在 MVC 的基础上采用了面向接口/协议编程，最终使业务逻辑代码更易测试。如果结合 Clean Architecture，还可以有效地减轻我们的思维负担。

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

App 任务

在构建 App 的过程中，我们需要思考以下问题：

1. 谁负责构建 model 和 view，以及将两者连接起来？
2. 如何根据 view 的变更来更新 model？
3. 如何将 model 中的数据应用到 view 上？
4. 如何处理导航、非 model 相关的状态？
5. 要采取怎样的测试策略来提高测试覆盖率？

想清楚这些核心问题之后，解耦、测试等问题也就迎刃而解了。

MVC

下图展示了我们期望的 MVC 模式，Controller 介于 View 和 Model 之间，并协调这二者之间的工作：

然而，很多时候我们在 iOS 开发工作中用到的 MVC 模式是这样的：

在这种情况下，Controller 和 View 耦合到了一起，MVC 也成了 Massive View Controller 笑柄。如果项目规模比较小，而且不需要做单元测试，MVC 是最易用、最实用的模式。确实非常简单粗暴，如果不考虑项目质量，这样开发是最省事的~

如果您依然钟爱 MVC 模式，又希望项目中的业务逻辑代码易测试，您可以参考 Ficow 的这篇文章：基于【依赖注入】和【控制反转】构建易测试的代码

MVP

MVP 可以有效地帮助我们解决 MVC 存在的问题。此时，Presenter 负责协调 View, Controller 与 Model 之间的工作：

Presenter 可以很好地组织业务逻辑，我们可以为其添加测试代码来验证业务逻辑的正确性，从而保证整个项目的质量。

如果您的项目规模不大，而且您希望方便地添加测试，MVP 会是一个比较好的选择。

很多人认为，MVP 只不过是把 MVC 中的 C 换成了 P，其实不然。

两者最主要的区别在于：

1. MVP 需要借助协议将 View 和 Model 进行抽象，在 Presenter 中依赖的是协议，而不是具体的类型，如：UIView 等。
2. 由于 Presenter 通过协议与 View 进行交互，Presenter 可以不引入任何 View 层面的依赖，如： UIKit 等框架。

凭借这些特点，MVP 比 MVC 具有更好的可测试性。

想了解更多的差异点，您可以参考 What are MVP and MVC and what is the difference?

关于示例代码，您可以参考 ios-mvp-clean-architecture 这个项目。其核心思想如下：

• 借助协议，Presenter 依赖的 UseCase, View 和 Router 在初始化时被注入，最终实现整个 Presenter 可测试。
• 非测试状态下，由 Configurator 来完成各部分的依赖注入工作。

总结

其实，这些 App 设计模式都是在按照职责对各个功能模块进行划分，以此来实现模块间的解耦。解耦后，开发、维护和测试也就变得相对容易一些。

这就像住宅一样。小宅子一般不会有太多的空间分类，而大宅子就会有各种室、各种厅。我们的人脑天生就很擅长进行分类，根据不同的功能对代码进行归类，就可以帮助我们更好的管理这些代码。

如果一个大宅子不进行合理的划分，我们很难想象，住在这个大宅子里的人会有怎样的居住体验呢~

参考内容：
App 架构 - objc.io
The Clean Architecture
ios-clean-architecture
ios-mvp-clean-architecture
What are MVP and MVC and what is the difference?