MVC vs MVP vs MVVM：常见的Android架构模式解释

作为一名开发人员，您一定听说过架构模式。 在我们的 Android 世界中，最知名的是MVC 、 MVP和MVVM 。 您可能知道它们的特点，但您知道它们的区别以及何时使用它们吗？

如果你问自己这些问题，这篇文章就是给你的。

MVC – 模型-视图-控制器

模型-视图-控制器 (MVC)是一种有助于组织应用程序结构的架构模式。 它将其职责分为三层：模型、视图和控制器。

需要安卓专家？

跟我们工作！

• 模型——数据层，负责管理业务逻辑并支持网络或数据库 API。 该模型使用远程和本地数据源来获取和保存数据。 这是处理业务逻辑的地方。
• View – UI 层，负责从 Model 到用户的数据可视化。 它管理数据的呈现方式，包括图形界面。
• 控制器——集成视图和模型层的逻辑层。 控制器的工作是接管用户输入并确定如何处理它。

您可以在下图中快速查看各个组件的通信方式：

这个怎么运作？

多年来出现了几种 MVC 变体，但我将在这里提到两个最流行的变体：被动模型和主动模型。

被动模型

在这个版本的 MVC 中，Controller 是唯一操纵 Model 的类。 为了很好地说明这个过程，我将使用下图：

1. 控制器响应用户的操作并联系模型。
2. 当模型改变时，控制器告诉视图更新它的数据。
3. 视图从模型中获取更新的数据并将其显示给用户。

活动模型

在这个版本的 MVC 中，除了 Controller 之外的其他类操作 Model。

在这种情况下，使用了观察者模式，并将视图注册为模型观察者。 多亏了这一点，当模型发生变化时，视图将不断更新。

优点

1. MVC 模式极大地支持了分离问题。 它增加了代码的可测试性并促进了其扩展，从而可以轻松实现新功能。
2. Model 类没有引用 Android 系统类，因此非常容易进行单元测试。
3. 控制器不扩展或实现任何 Android 类。 它使单元测试成为可能。

缺点

1. 视图与控制器和模型相关。
   • View 对 Model 的依赖主要是在高级 View 中造成麻烦。 为什么？ 如果模型的角色是提供原始数据，那么视图将接管用户界面逻辑的处理。
     另一方面，如果 Model 将直接显示准备显示的数据，我们将获得同时支持业务逻辑和 UI 逻辑的 Model。
   • 模型的主动实现以指数方式增加了类和方法的数量，因为每种数据类型都需要观察者。
   • 当视图同时依赖于控制器和模型时，对 UI 逻辑的更改可能需要对多个类进行更新/更改，从而降低了模式的灵活性。
2. UI 逻辑处理不限于一类。 对于一个新手程序员来说，这是一个相当大的问题，Model、View 和 Controller 之间的职责分工几率非常高。
3. 随着时间的推移，尤其是在具有贫血模型的应用程序中，越来越多的代码开始被发送到控制器，使它们变得臃肿而脆弱。

概括

View 对 Model 的依赖以及 View 中的逻辑会显着降低我们应用程序中代码的质量。 我们可以通过选择其他模式来减少这种危险，尤其是那些建议用于移动应用程序的模式。 在下面阅读它们。

MVP——模型-视图-演示者

Model-View-Presenter (MVP) 是一种架构模式，我们可以使用它来处理 MVC 模式的弱点。 它提供了模块化、可测试性和更清晰、更易于维护的代码库。

MVP 将应用程序结构分为View 、 Model和Presenter层：

• 模型——类似于 MVC 模式。
• View ——UI层，负责以Presenter指定的方式将数据呈现给用户。 它可以通过活动、片段或任何通用视图来实现。
• Presenter – 在 View 和 Model 层之间进行调解的逻辑层。 它同时联系 View 和 Model 层并对用户执行的操作做出反应。

这个怎么运作？

在MVP中，View 和 Presenter 是完全独立的，通过抽象相互通信。 Contract 接口类定义了它们之间的关系。 多亏了他们，代码更具可读性，层之间的联系也很容易理解。 如果您对实现细节感兴趣，请阅读 Model-View-Presenter：Android 指南。

值得一提的是，Presenter 不能有任何对 Android 特定 API 的引用。

请参阅下图，以全面了解各个组件之间的数据交换过程。 出于本文的目的，此示例已简化：

1. 用户执行操作。
2. Presenter 对用户的操作做出反应并向模型发送适当的请求。
3. 模型被更新，新数据被发送到 Presenter。
4. Presenter 准备要显示的数据并将其发送到 View。
5. 视图向用户显示数据。

优点

1. 我们可以轻松地测试 Presenter 逻辑，因为它不依赖于任何 Android 特定的视图和 API。
2. View 和 Presenter 是完全分开的，这使得模拟视图变得容易，使得单元测试比 MVC 中的更肤浅
3. 我们只有一个类来处理与视图呈现相关的所有事情——Presenter。

缺点

1. Presenter和 Controller 一样，倾向于积累额外的业务逻辑。 为了解决这个问题，分解你的代码并记住创建只有一个职责的类。
2. 虽然这对于 Android 应用程序来说是一个很好的模式，但在开发小型应用程序或原型时会让人感到不知所措。

概括

与 MVC 相比，这种模式要好得多。 它解决了 MVC 模式的两个关键问题：

1. View 不再同时引用 Controller 和 Model。
2. 它只有一个类来处理与视图表示相关的所有事情：Presenter。

MVVM – 模型-视图-视图模型

Model-View-ViewModel (MVVM) 是一种基于事件的模式。 多亏了这一点，我们可以对设计变更做出快速反应。 这种架构模式允许我们将 UI 与业务和行为逻辑分离，甚至比 MVC 或 MVP 的情况还要好。

• ViewModel – 处理将数据从模型传递到视图层并处理用户操作。 值得一提的是，它为 View 提供了数据流。
• 视图——UI 层负责在图形界面中呈现数据、系统状态和当前操作。 除此之外，它初始化 ViewModel 并将其与 View 元素绑定（通知 ViewModel 用户操作）。
• 模型——与 MVC 相同——没有变化。

这个怎么运作？

MVVM模式的思想主要是基于View层（Observer 模式）观察ViewModel层中数据的变化，并通过数据绑定机制来响应变化。

MVVM 模式的实现可以通过多种方式实现。 但是，值得在其中包含数据绑定机制。 得益于此，视图层的逻辑被最小化，代码变得更有条理，测试也更容易。

如果 MVP 模式意味着 Presenter 直接告诉 View 要显示什么，则MVVM ViewModel会公开 View 可以关联到的事件流。 ViewModel 不再需要像对 Presenter 那样存储对 View 的引用。 这也意味着现在不需要 MVP 模式所需的所有接口。

视图还会通知 ViewModel 各种操作，如上图所示。 因此，MVVM 模式支持 View 和 ViewModel 之间的双向数据绑定。 View 有对 ViewModel 的引用，但 ViewModel 没有关于 View 的信息。

优点

1. 单元测试更直接，因为您不会沉迷于视图。 当模型在测试时发生变化时，验证可观察变量是否正确定位就足够了。
2. ViewModel 对单元测试更加友好，因为它们只是公开状态，因此可以在不测试如何使用数据的情况下进行独立测试。 简而言之，不依赖于视图。
3. 只有 View 包含对 ViewModel 的引用，而不是相反。 这解决了紧耦合问题。 一个 View 可以引用多个 ViewModel。
4. 即使对于复杂的 View，我们也可以在同一个层次结构中拥有不同的 ViewModel 。

缺点

1. 在复杂的 UI 中管理 ViewModel 及其状态有时对初学者来说是一个挑战。

概括

MVVM结合了 MVP 提供的优势，同时利用了数据绑定和基于事件的通信的优势。 结果是模型控制尽可能多的操作的模式，具有高度的代码分离和可测试性。

MVC vs MVP vs MVVM：比较

MVC vs MVP vs MVVM：总结

MVP 模式和 MVVM 模式都明显优于 MVC 模式。 您选择哪种方式实际上取决于您的喜好。 但是，我希望本文向您展示了它们之间的主要区别，并使您更容易做出选择。

寻找替代方案？

选择跨平台！

参考书目：

1. Cervone, S. (2017) Model-View-Presenter：Android 指南。
2. Dang, AT (2020) MVC vs MVP vs MVVM。
3. Muntenescu, F. (2016) Android 架构模式第 1 部分：模型-视图-控制器。
4. Muntenescu, F. (2016) Android 架构模式第 2 部分：模型-视图-演示者。
5. Muntenescu, F. (2016) Android 架构模式第 3 部分：模型-视图-视图模型。