作者博客
http://www.jianshu.com/u/cd0fe10b01d2
文章目录
前言
文件目录
基本的Activity里面的MVP架构
数据层架构
关于测试用例
前言
或者你已经看过了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
