Android MVP + Clean Architecture 深入浅出(译、学习)

转载请标明出处 http://www.jianshu.com/p/e8e81a8f08b1

Github官方地址 

---

工程作者Jorge J. Barroso (Karumi)

简述

工程原理基于Clean Architecture.

工程例子基于MVP sample

MVP Sample

MVP

之前的图，看下对比，Presentation layer 与  Data Layer 之间新增 domain layer  . App 分成三层.

MVP Clean Architecture

MVP:  是MVP sample里的

Domain:包含业务逻辑. Domain layer 的驱动是Presenter通过use cases 或interactor . User case 可以支持所有Developer从Presentation Layer 想执行的事情

Use case 通常翻译成"用例"  何为Use case?  "是一件事的场景描述"

Repository: 是MVP sample里的

 重点概念

与MVP sample最大的区别是使用Domain layer 和 use cases . 把Domain Layer层从Presenter 移出是帮助避免Presenter存在重复的domain 代码(e.g.Task filters).

Use cases 定义了一组App需要的操作.它的Class名称带有明显目的，会提高可读性(seetasks/domain/usecase/).

Use cases对于我们重复使用domain代码是十分有益的.CompleteTask是一个很好的例子，例如它同时使用了TaskDetailPresenter与TasksPresenter. 

通过命令模式command pattern Use cases 在后台线程完成执行.Domain Layer 的存在完全减弱 Android SDK 和 第三方 lib 的依赖.(Java独立代码)

问题/纪要

Use cases 运行在主线程之外，这对Android apps来说是一个好的解决方案. 这样做尽可能避免堵塞UI线程. 我们决定使用命令模式command pattern来执行线程池中的Use cases. 但我们也可以通过RxJava 和 Promises 来实现.

我们使用异步的仓库(Data Source)但没有必要一定这样做. 因为 Use cases 就已经不在主线程执行的. 这样会尽可能的保持原生的例子.

我们建议为View、Domain、API层使用不同的Model . 但在这个Case下所有Model都是不变的，因此没必要重复创建维护他们.  如果View包含Android相关联字段，我们就使用两种Model . 一个用在Domian Layer 一个用在View Layer ,并且维护一个mapper去转换彼此.

CallBack(回调) 相关存在一个 onError() 方法, 在真正的app中应该包含报错的信息.

测试性

应用Clean Architecture思想后

Domain Layer ：过单元测试(Unit Test) 可测

也可以通过集成测试来扩展，把它覆盖到从View 到 Repository

三层分离，上层依赖下层，所以下层永远不知道有上层。这三层皆可独立测试

依赖

除了依赖一些测试lib , 其他一律不需要

特征

复杂性 - 可理解性

使用框架/lib/tool  ?   没有

概念复杂性

中等偏下 .  这还是MVP ，不过是以增加新的 Domain Layer 来处理业务逻辑.

代码量

新增Domain Layer层后，添加了一些class 和代码量如图

MVP-Clean-Architecture

可维护性

易于拓展和新增功能 / 学习陈本

非常简单. 这种方式更加擅长