跟着google学习mvp架构

作者博客

http://www.jianshu.com/u/cd0fe10b01d2

文章目录

1. 前言
2. 文件目录
3. 基本的Activity里面的MVP架构
4. 数据层架构
5. 关于测试用例

1

前言

或者你已经看过了google官方相关的MVP样例。

https://github.com/googlesamples/android-architecture

这章节内容，将会带大家分析google官网这个架构的好东西。

Todo-mvp的样例，其实是一个简单的记事App。

2

文件目录

从文件目录我们很简单的看

addedittask:编辑记事界面

data：数据架构设计

statistics：显示任务记录

tasks:记事首页

util:工具类

base:基本接口

这里简单分析一下目录里面，基本就是每个Activity为独立的文件夹，然后数据文件夹里面分为远端和本地，然后base的文件都放在主目录中。

3

基本的Activity里面的MVP架构

请认真观看官网的这张架构图

图示中非常清楚的说明了MVP的基础架构，Presenter和View之间可以相互操作，数据交流，Model（模块）此处是离开Activity的全部图示都算是Model数据层，可以看到，其实通过一个REPOSITORY来管理数据存储，Remote data source和Local data source代表远端（网络）和本地（SQL）的数据来源。

MVC和MVP最大的区别在于，MVC中M和V是可以通信交流，而MVP中M和V是没法直接交流的。

Base的View

Base的Presenter

很明显都是以接口的方式来利用组合来做公共的基础接口。

我们以TaskActivity为例

其模块内都把View和Presenter再次封装到TasksContract统一的接口容器里面。

View接口中，是定义所有更改界面需要的方法。

而Presenter接口中，定义所有控制逻辑的方法。

其简单图示关系

MVP是通过接口的方式来解耦，所以View和Presenter都是通过接口来解耦。

在TaskActivity中

初始化TasksFragment，其继承了Contract的View，而初始化了TaskPresenter，其会继承Contract的Presenter。

就正如架构中的这个黄色部分了

注意初始化的时候Presenter的时候是传入了Model和View的模块，那么才可让Presenter作为内容控制者来统筹全局

TasksRepositroy相当于数据提供者（Model），其本身也是通过接口来解耦，而TasksContract.View相当于界面显示（View），也是接口。

然后View通过setPresenter的方法来，让其和Presenter相关关联。（View和Presenter是可以相互关联的）

4

数据层架构

从这个图可以很清楚看明白数据层是通过REPOSITORY作为入口，分别获取远端数据和本地数据的。

其类图如下，这样看应该比较清晰一点吧。

TaskDataSource是基础接口，做成基础接口

这里的TasksRemoteDataSource只是用一个Map存储来模拟远端的存储，实现TasksDataSource的接口。

而TasksLocalDataSource 用的是本地的数据来存储数据。

最主要的TasksRepository就是做出包装给统一的接口给外部调用。

可以清晰的看到初始化的时候，会传入远端的对象和本地存储的的对象。

然后外包统一的接口给外部调用，以getTasks的方法为例

远端调用的方法，也是通过LoadTasksCallback回调。

这里看了数据层运用的，看起来是简单的封装，其实算是外观模式加接口的变种。

其封装好里面调用的多个类流程代码，通过一个接口类，让外界调用它的流程。

5

关于测试用例

国内现在很多公司以前的开发习惯都不会很注重自动化测试用例，因为自动化用例，需要些测试代码。但是国外的研发，非常重视测试，而且有自己一套的测试流程。测试用例，很可能就是研发自己写出来的。

国内大体上，现在也越来越注重测试了，特别大型App。

这里顺便通过这个todo-mvp 顺便也给大家普及一些测试代码的相关知识吧。

testCompile是声明本地测试的依赖，androidTestCompile是声明Instrumented测试依赖。

对于单元测试，需要预先了解以下内容：

• Android Studio的test和AndroidTest
• AndroidJUnitRunner：一个兼容Junit4的Andriod单元测试框架
• Mockito：单元测试利器
• Espresso：支持UI测试的单元测试框架

• P层：不需要任何Android环境，因此使用Junit测试即可
• V层：使用Google强大的Espresso进行UI的测试
• M层：涉及到数据库相关操作，因此需要依赖Android环境，使用AndroidJUnitRunner进行测试

View层：

职责：

MVP模式下，View层终于扬眉吐气了，View本身该做的事情都能做了，比如UI布局，数据渲染，点击按钮交互等等

测试方式：

以正常小QA的测试思维方法，就可以来定义这一层的测试方式，测试过程中需要真机或模拟器，并做真实的操作。

测试选型：

依赖于Android环境，用谷歌强大的Espresso+AndroidJUnitRunner，Espresso用于模拟和验证各种各样的UI操作，代码存放于AndroidTest中。

Presenter层：

职责：

这一层是拉皮条的，负责M和V层的对接，所以有较少的处理输入输出的机会，他只用来控制逻辑，去调用相应的Model和View的逻辑。

测试选型：

他的职责决定了他很少去断言输入输出，测试逻辑覆盖的路径是否正确即可，因此他与Android环境无关，用Junit+Mockito测试即可，代码存放于test中。

Model层：

职责：

负责数据的存取，数据可能来自于网络、数据库和内存

数据库增删改查：

需测试数据存取的准确性，依赖Android环境进行测试，因此使用AndroidJUnitRunner，代码存放于androidTest中

网络请求：

不测试真实的网络请求，但提供了Fake供其他层调用测试。

封装的门面类：

决定了数据的来源和去向是来自于本地数据库 or 网络 or 内存，此为真正对其他层暴露的Model类。此类不做数据准确性的验证，只做mock测试，验证覆盖路径。UT选型Junit+Mockito，代码存放于test中。

这里想深入了解有关测试的内用可以看Android官方MVP项目单元测试。

http://blog.csdn.net/zrbcsdn/article/details/51306370