MVP架构学习笔记|青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第6天
前言
一个 App 的架构需要处理两个任务：
- 更新 Model —— 处理View收到的用户请求
- 更新View —— 将Model的数据表现到View上
简单来说就是为了将业务和视图的实现代码分离。
MVC = Model-View-Controller，MVP = Model-View-Presenter，MVVM = Model-View-ViewModel是三个最常用的架构模式。
MVP与MVC的区别
| MVC | MVP | ||
|---|---|---|---|
| Model | 业务逻辑和实体模型 | Model | 业务逻辑和实体模型 |
| View | 对应于布局文件 | View | 对应Activity，负责View的绘制与用户交互 |
| Controller | 对应Activity等 | Presenter | 负责完成View与Model的交互 |
Model,View与Presenter
-
Model：负责管理业务数据逻辑，如网络请求、数据库处理
Model = 数据 + 业务逻辑，它既保存程序的数据，也定义了处理该数据的逻辑，从数据的维度可细分为数据的定义、储存和获取。
-
View：Activity\Fragment 和 Layout XML 文件
View负责接收用户的交互请求并展示数据信息给用户，展示的数据从Model中获取。
-
Presenter： 负责处理表现逻辑
Presenter为Model与View之间的桥梁，用于控制程序的流程。
MVP架构
MVP三件套的关系图如下
MVP 之间是通过接口来通信的，各层都有各自的接口来实现相应功能。
其交互流程为：用户操作 View 层，产生了一个事件; Presenter 接收事件，并对其作出反应，请求 Model 层; Model 层作出处理后通知给 Presenter, Presenter 进而再通知到 View 层。
在实现细节上，View 和Presenter中间会定义一个协议接口 Contract，该接口将约定View与Presenter的交互逻辑。这样Activity将作为View的一部分只处理UI事务。
MVP的缺点
对View的操作都在Presenter中，所以View和Presenter的交互可能会过于频繁。Presenter与视图的绑定过于紧密，一旦视图改变，Presenter也要改变。
