Android当中的MVP模式（一）基本概念

摘要：Github上看到很多项目，都是 MVP+RxJava+Retrofit+Dragger2 这种架构，再加上一个 OkHttp， 虽说这几个东西，我都或多或少听过，用过，但是从来没有认真的研究过，没有把他们整合起来开发一个应用。从 MVP 开始，认真学习这几个框架，然后整合起来，做一个应用。先立一个 FLAG！

为什么要使用MVP

在传统的Android开发中，我们一般是使用MVC模式进行开发的。

 

传统MVC模式介绍：

1. View: 视图层，对应xml文件
2. Controller: 控制层，对应Activity和Fragment层，进行数据处理
3. Model：实体层，负责获取实体数据

采用MVC模式的一个最大的弊端就是xml作为View层视图能力实在太弱，所以一般情况下我们都是通过Controller层来辅助处理一些视图的。这样的结果就导致Controller既作为控制层的同时又承担了View层的大部分功能，采用MVC模式往往会导致Activity和Fragment中的代码非常复杂。我们将Android中采用的MVC模式称为MV模式更加恰当。

MVP模式介绍：

1. View: 视图层，对应xml文件与Activity/Fragment
2. Presenter: 逻辑控制层，同时持有View和Model对象
3. Model: 实体层，负责获取实体数据

    

MVP模式的流程图如下：

采用MVP模式的优势是：

1. 把业务逻辑抽离到Presenter层中，View层专注于UI的处理。
2. 分离视图逻辑与业务逻辑，达到解耦的目的。
3. 提高代码的阅读性。
4. Presenter被抽象成接口，可以根据Presenter的实现方式进行单元测试。
   可拓展性强。

    

采用MVP模式的缺点：

1. 项目结构会对后期的开发和维护有一定的影响。具体视APP的体量而定。
2. 代码量会增多，如何避免编写过多功能相似的重复代码是使用MVP开发的一个重点要处理的问题。
3. 有一定的学习成本。
   综上所述，在Android上采用MVP模式的优势是：大大优化代码的维护性与拓展性的同时对代码进行深度解耦，使各个层级的分工更加明晰。

    

一个简单的应用

模拟Android中登陆的功能

 

界面

 

项目结构

 

 

从上图中可以看到，一个简单的基于 MVP 的项目，最少也需要创建 6 个文件夹，分别是 M、V、P 的接口和它们各自的实现类，其中 LoginActivity 就是 View 层的具体实现，它只需要负责处理 UI 的逻辑，而业务相关的逻辑都抽象到 LoginPresenter 中，这样就避免了传统开发中 Activity 、Fragment 既处理 UI 又负责业务逻辑的情况。

代码实现

ILoginView：

view层只负责和 UI 相关的操作，那么在这个小 Demo 中，和 UI 相关的操作有如下几点：

1. 从EditText中拿到用户输入的userName
2. 从EditText中拿到用户输入的password
3. 在登录过程中需要展示一个progressbar，登录过程结束之后隐藏这个progressbar
4. 展示登录成功后的view
5. 展示登录失败后的view

综上五个操作，所以有了ILoginView中的五个接口

LoginActivity：

 

当点击登录按钮时，会将请求服务器合适账号密码这个过程交给presenter层去处理，所以在LoginActivity里，会有preserent的引用。

ILoginPersenter：

presenter层处理业务逻辑，有如下几点:

1. 负责接收model的返回结果并且处理
2. 将处理的结果以特定的形式，传递给view层，让view层去展示
3. 通知model层去向数据源请求数据

LoginPresenter：

 

因为presenter层相当于一个中间交互人，所以它必须要持有对 view 、model 层对象的引用。

ILoginModel：

model负责数据的存取：

在这个Demo中，数据的存取使用一个线程和简单的字符串判断来模拟。

LoginModel：

 

因为model层需要将获取的数据传递给presenter层去做处理，所以此处也需要持有对presenter层的引用。

这样一来就成功的将简单的登录案例，由MVP模式来实现了,

• 在 LoginActivity 中处理的都是和 UI 相关的，
• 在 LoginPresenter 中处理的是业务的逻辑，
• 在 LoginModel 中处理的是网络数据获取。

小结

Presenter—交互中间人

主要作为沟通 View 和 Model 的桥梁，它从 Model 层检索数据后，返回给 View 层，使得 View 和 Model 之间没有耦合，也将业务从 View 角色上抽离出来。

View—用户界面

View 通常是指Activity、Fragment或者某个 View 控件，它含有一个 Presenter 成员变量。通常 View 需要实现一个逻辑接口，将 View 上的操作转换给 Presenter 进行实现，最后，Presenter 调用 View 逻辑接口将结果返回给 View 元素。

Model—数据的存取

对于一个结构化的 APP 来说，Model角色主要是提供数据的存取功能。Presenter 需要通过 Model 层存储、获取数据，Model就想一个数据仓库。更直白的说，Model 就是封装了数据库 DAO 或者网络获取数据的角色，或者两种数据获取方式的集合。

MVP 并不是一个标准化的模式，它有很多种实现方式，也可以根据自己的需求去修正MVP的实现方式，可以随着 Presenter 的复杂程度而变化，只要保证是通过 Presenter 将 View 和 Model 解耦，降低类型复杂度，各个模块单元可以独立测试、独立变化，这就是正确的方向。