跟着 google 学习 mvp 架构

阅读 3484
收藏 106
2017-05-17
原文链接:mp.weixin.qq.com

作者博客

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

评论