【Android】浅析MVC与MVP

什么是架构？

架构（Architecture）在软件开发中指的是软件系统的整体设计和结构，它描述了系统的高层组织方式，包括系统中各个组件之间的关系、依赖、交互方式，以及这些组件如何协同工作来完成系统的功能。

架构不仅仅是指代码的结构，它还涵盖了系统的各个方面，包括：

组件的划分：将系统拆分成模块、类、服务等单元。
组件间的交互：不同模块、组件如何传递信息、调用服务等。
数据流：数据如何在系统中流动，从输入到输出的路径是什么。
非功能性需求：如何考虑系统的性能、可扩展性、安全性、可维护性等。

架构模式，其实更多的是一种思想，一种规则，往往一种架构模式可能会有不同的实现方式，而实现方式之间，只有合适与否，并没有对错之分。

为了解决特定的问题而提出
按照特定的原则将系统整体进行模块／组件／角色的划分
建立模块／组件／角色间的沟通机制

摘自：https://zhuanlan.zhihu.com/p/83635530

MVC架构

在不同的框架或平台上，MVC（Model-View-Controller）架构的具体实现方式会有所不同，但其核心思想是不变的：将数据、逻辑与用户界面分离，以提高应用程序的可维护性、可扩展性和灵活性。

Model-View-Controller

MVC 将应用程序分为三个主要的部分：

Model

Model 负责应用程序的业务逻辑和数据处理，它代表了应用中的数据和状态。所有与数据相关的操作（如网络请求、数据库操作等）都在Model中进行。

职责：管理应用的数据，包括获取数据、存储数据、处理数据、数据验证等。

在Android中的体现：

可以是任何与数据处理相关的类，比如网络请求类、数据库操作类等。
例如：通过Room数据库、SQLite数据库、或者API接口获取数据。

View

View 负责显示数据，是应用程序用户界面（UI）的表现部分。View直接与用户交互，展示Model中的数据并将用户操作传递给Controller进行处理。

职责：展示Model中的数据，并响应用户的交互操作（如点击按钮、输入文本等）。

在Android中的体现：

XML布局文件（Layout）或Java中的UI元素（如TextView、Button等）。
Fragment或Activity中的onCreate()方法中设置布局和更新UI的代码。
View本身不应该包含业务逻辑，只负责显示数据和响应事件。

Controller

Controller 负责协调Model和View之间的交互，通常处理用户输入并将这些输入传递给Model，之后将Model处理的数据结果反馈给View。

职责：接收用户操作的输入，调用Model更新数据，并通知View来更新UI。

在Android中的体现：

Activity和Fragment通常充当Controller的角色，因为它们负责管理UI逻辑和用户交互。
在Activity或Fragment中，通过监听用户的交互事件（如点击事件）来修改Model，然后更新View。

解决什么问题

如果不使用架构进行开发，会导致 Activity / Fragment 逻辑臃肿，不利于扩展。

所以 MVC 就要解决的问题就是：控制逻辑，数据处理逻辑和界面交互耦合。

数据的流向

MVC 模式的工作流程

用户操作 View：用户通过UI进行某些操作（如点击按钮、输入文本等），这些操作通过事件监听传递到Controller。
Controller 更新 Model：Controller接收用户的操作，并根据操作调用Model来获取或更新数据（比如向API发送请求，或者从数据库中获取数据）。
Model 变更通知：Model处理完数据后，将更新后的数据通知给Controller或直接通知View。
View 更新显示：Controller根据Model的数据变化来更新View，从而将新数据展示给用户。

在传统的 MVC 模式中，View 和 Model 可以直接通信。也就是说，View 可以直接读取 Model 的数据，而不需要通过 Controller。这种直接通信导致 View 和 Model 之间的耦合度较高，尤其在复杂应用中，难以维护和测试。

MVC 架构模式的优缺点

优点：

结构清晰，职责划分清晰
降低耦合
有利于组件重用

缺点：

其实我们上述的示例，已经是经过优化的 MVC 结构了，Activity / Fragment 会承担 View 和 Controller 两个角色，就会导致 Activity / Fragment 中代码较多
Model 直接操作 View，View 的修改会导致 Controller 和 Model 都进行改动
增加了代码结构的复杂性

虽然MVC是一个经典的设计模式，但在Android开发中，由于Activity和Fragment承担了太多的角色（既作为Controller，又直接操作View），会导致代码臃肿，维护困难。因此，Android开发中更多地使用MVP（Model-View-Presenter）或MVVM（Model-View-ViewModel）架构模式，来更好地解耦UI和业务逻辑。

MVP

MVP（Model-View-Presenter）是Android开发中的一种架构模式，旨在通过更清晰地分离职责，解决MVC中Activity和Fragment过度承担的角色，使代码更加模块化、可维护性更高。MVP将逻辑代码与UI代码解耦，避免了UI组件直接与业务逻辑耦合。MVP是对MVC模式的改进，非常适合中小型Android应用。

Model-View-Presenter

Model（模型） Model在MVP中负责数据的处理和业务逻辑，跟MVC中的Model角色一致。它与Presenter通信，提供数据和执行相应的业务逻辑。
View（视图） View负责展示UI，与用户进行交互。它只处理用户输入和UI更新，不包含业务逻辑。在MVP中，View通过接口与Presenter通信，将事件交由Presenter处理，而不是自己操作业务逻辑。
Presenter（控制器） Presenter是MVP的核心，它作为Model和View之间的中介，负责从Model获取数据并通知View进行更新。Presenter中不应该包含任何UI代码，它只处理逻辑和决定如何将数据传递给View。

解决什么问题

MVP 要解决的问题和 MVC 大同小异：控制逻辑，数据处理逻辑和界面交互耦合，同时能将 MVC 中的 View 和 Model 解耦。

数据流向

MVC 和 MVP 的核心区别：角色通信

MVC 中，View 和 Model 直接交互。这意味着 View 可能直接访问 Model 来获取数据，也可以监听 Model 的变化并更新界面。Controller 作为用户输入的处理者，接收用户输入并将其转发给 Model 或 View。这种直接交互可能导致View和Model之间的耦合度较高。

MVP 则通过 Presenter 作为中介，解耦了 View 和 Model 之间的直接通信。View 不会直接访问 Model，所有的数据交互、逻辑处理、UI 更新都通过 Presenter 进行。View 只负责呈现数据，而不涉及任何业务逻辑。Presenter负责处理业务逻辑，并且通过接口与View和Model交互，从而实现低耦合。

MVP 中的数据流向

MVP 模式下的数据流向可以总结为以下几个步骤：

用户事件触发（View -> Presenter）：

用户在 UI 界面（View）上执行操作（如点击按钮、输入文本等）。View 接收到用户的交互后，不直接处理逻辑，而是将事件传递给 Presenter。

业务逻辑处理（Presenter -> Model）：

Presenter 负责处理用户的输入，并做出相应的业务逻辑处理。如果需要修改数据或与后端进行交互，Presenter 会通过接口调用 Model 的方法，来处理业务逻辑或更新数据。

数据更新（Model -> Presenter）：

Model 根据 Presenter 的指令更新数据或获取数据。当 Model 处理完数据之后，它会将结果返回给 Presenter。

界面更新（Presenter -> View）：

Presenter 收到来自 Model 的新数据后，将这些数据传递给 View，从而驱动 UI 界面的更新。View 只负责根据 Presenter 提供的数据更新界面，不会进行数据处理或逻辑处理。