【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等。
参考: