【Android】浅析MVC与MVP
什么是架构？
架构（Architecture）在软件开发中指的是软件系统的整体设计和结构，它描述了系统的高层组织方式，包括系统中各个组件之间的关系、依赖、交互方式，以及这些组件如何协同工作来完成系统的功能。
架构不仅仅是指代码的结构，它还涵盖了系统的各个方面，包括：
- 组件的划分：将系统拆分成模块、类、服务等单元。
- 组件间的交互：不同模块、组件如何传递信息、调用服务等。
- 数据流：数据如何在系统中流动，从输入到输出的路径是什么。
- 非功能性需求：如何考虑系统的性能、可扩展性、安全性、可维护性等。
架构模式，其实更多的是一种思想，一种规则，往往一种架构模式可能会有不同的实现方式，而实现方式之间，只有合适与否，并没有对错之分。
- 为了解决特定的问题而提出
- 按照特定的原则将系统整体进行模块／组件／角色的划分
- 建立模块／组件／角色间的沟通机制
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提供的数据更新界面，不会进行数据处理或逻辑处理。
举个栗子吧~：
以一个简单的登录流程为例：
用户输入用户名和密码，点击登录按钮：
用户在 View 中（例如 LoginActivity）输入用户名和密码，并点击"登录"按钮。View 不直接处理输入，而是将事件通知给 Presenter。例如：presenter.onLoginButtonClick(username, password)。
Presenter 接收用户输入，开始验证逻辑：
Presenter 接收到用户输入后，执行登录验证逻辑。Presenter 通过调用 Model 的方法（例如 model.login(username, password)）来进行登录操作。
Model 处理登录逻辑：
Model 负责处理登录的具体业务逻辑，例如查询数据库或通过网络请求验证用户名和密码。验证成功后，Model 将结果返回给 Presenter（例如成功或失败的状态）。
Presenter 获取验证结果，并通知 View 更新界面：
Presenter 接收到登录的结果后，决定如何通知 View 更新界面。如果登录成功，Presenter 可能调用 View 的方法来显示"登录成功"的消息；如果失败，则显示"登录失败"的提示。
MVP 架构模式的优缺点
优点：
- 结构清晰，职责划分清晰
- 模块间充分解耦
- 有利于组件的重用
缺点：
- 会引入大量的接口，导致项目文件数量激增
- 增大代码结构复杂性
结语
本文仅仅对MVP和MVC做了一个小的总结，希望在日后可以学习更多有关架构模式的知识，例如：依赖注入、响应式编程、MVVM等。
参考：