MVP 模式及官方示例分析

MVP 简介

MVP 即 Model-View-Presenter，是一种从 MVC 模型演化而来的用于 Android 开发的软件开发模式，目标在于将应用程序中的用户交互、界面显示部分与后台业务逻辑处理部分相分离，提升应用程序的稳定性和代码的可维护、可测试性。

Model：模型层，即数据层，数据的存储、查询、获取、状态转变等操作均交由该层完成；
View：视图层，界面显示、用户交互等功能由该层实现，在 Android 程序中，可能为一个 Activity、一个 Fragment 或一个 View 等；
Presenter：该层主要提供两类功能：1）作为 Model 和 View 的媒介，负责在两者间传递数据，如从 Model 层获取数据交给 View 进行展示，从 View 层得到用户输入信息，交由 Model 加以保存等；2）处理后台任务，控制业务流程等。

MVP 结构图

上图为 MVP 模式的基本交互结构图，从图中可知：
1） MVP 结构中 View 和 Model 并不直接进行交互，而是通过中间媒介 Presenter 间接进行交互；
2） 一般来说，View 和 Presenter 之间是相互持有的关系，即 View 中持有与其关联的 Presenter，Presenter 也持有与自己进行交互的 View，即它们通过这种一一对应的关系进行信息交换；而 Presenter 和 Model 间属于单向持有关系，Presenter 中持有 Model，但 Model 中一般并不持有 Presenter，这是因为通常 Model 层与整个应用程序相关，而非与某个页面相关，如若让 Model 层通过持有 Presenter 的引用来进行信息交换的话，会导致每次对 Presenter 的增删操作都需要修改 Model 层的代码，不利于程序的扩展，而通过接口回调的方式来进行信息交换就可以避免这类情况发生，从而提升程序的可扩展性。

MVP 模式使用注意：

1. Presenter与View、Model的交互使用接口定义交互操作可以进一步松耦合也可以通过接口更加方便地进行单元测试；
2. MVP 模式的提出主要用于隔离界面显示与业务逻辑处理，所以在编码时需要注意区分这两者的界限，如对于一个 EditText，当只需要对输入内容进行简单的判空操作时，可以直接在 View 层完成，但如若需要进行更复杂的判断，如判断输入内容是否与已有内容冲突时，则需要交由业务逻辑层进行处理。

Todo 项目

项目组织结构

项目地址：https://github.com/googlesamples/android-architecture

该项目官方明明为 Android 架构蓝图，旨在采用不同的架构设计模式实现同一个 APP 功能来辅助开发者进行架构选择。该项目中包含了13 个已实现或正在实现中的小 Demo，本文主要基于 Todo-MVP 这个 MVP 基础实例架构进行分析。

项目架构目录

上图展示了 Todo-MVP 项目的组织结构。项目包含五部分：APP 功能实现部分和四个用于测试的目录，这四个测试目录分为两部分，分别用于 UI 层的测试和业务逻辑层的测试。APP 功能实现部分根据业务功能进行模块划分，主要有四个功能模块：addedittask（增加 / 修改任务）、statistics（数据统计）、taskdetail（任务详情）和 tasks（任务主页面），data 模块即项目的 Model 层，用于从本地数据库 / 远程网络中获取数据。 每一个功能模块内部均由四个部分构成：XXActivity、XXFragment、XXContract 和 XXPresenter，即统筹控制的 Activity，用户交互的 View，View 和 Presenter 需实现的接口定义和用于处理业务逻辑的 Presenter。可以看到官方示例项目的组织结构简洁明了，通过类名便可大致了解该类的主要功能，是学习的典范。

项目中的 MVP

下图以 AddEditTask 作为示例，简单描述了项目中的 MVP 结构。项目中使用了接口来松耦合，通过 XXFragment、XXPresenter 分别作为 View 和 Presenter，data 包作为 Model 来实现 MVP 模式。

MVP 轮廓示意

下面脑图对整个项目结构进行了描述。

Google Todo 项目脑图

** 要点分析：**

1. 项目中 Activity 的作用在于作为一个全局控制者，创建当前页面的 Fragment 和 Presenter，并将两者联系起来，具体而言：Fragment 作为参数传递给 Presenter 的构造函数，然后 Presenter 在构造函数中通过调用 Fragment 的 setPresenter() 方法将自身传递给 Fragment，这样便建立了两者的联系；
2. 项目中使用了 BaseView 和 BasePresenter 分别作为 View 和 Presenter 的基类，复用所有 View 和 Presenter 中均需使用的方法；
3. 契约类：XXContract 即为项目中的契约类，该项目将 View 和 Presenter 的接口统一由一个契约类来进行管理，不仅可以减少类数目，而且能够通过该类一目了然地获知当前页面中 View 和 Presenter 均有哪些主要功能，便于管理和维护；
4. 项目的模型层统一包含在 data 目录中，内部根据本地和远程进行功能划分，分别实现本地数据存储、获取和远程数据传输，清晰明了；

** 总结：**

1. 复杂度：本项目只实现了几个基本功能，整体代码量较小，复杂度较低；
2. 可测试性：MVP 架构很好地将 UI 层和业务逻辑层隔离，所以整体可测试性相当好，可以对 UI 层和业务逻辑层分别进行测试；
   3.可维护性和可扩展性：MVP 架构的引入，虽然代码量有了一定的上升，但是由于界限非常清晰，各个类职责都非常明确且单一，所以后期的扩展，维护都会更加容易。

** 参考：**

1. Android官方MVP架构示例项目解析
2. Introduction to Model-View-Presenter on Android
3. Google官方架构MVP解析与实战
4. Android 中的 MVP