16年底,笔者第一次接触了Clean Architecture的开发框架,虽然虽然不甚理解,但还是模仿着github上的demo开发了公司内部使用的一个小项目。使用后觉得不错,之后也用它陆陆续续开发了几个小的项目。本篇主要记录一下此时的一些小体会。
依赖关系
说到Clean Architecture,就一定会提到这张依赖关系图:
如图所示,外层依赖里层,里层不依赖外层。最外边的两层(UI以及Presenters)是视图层,用来呈现数据并与用户交互。中间(UseCases)是业务层,是执行业务逻辑的地方,这里一般执行,从不同数据源中获取数据的任务。最内层(Entities)是数据部分。
结构
上面是该框架的概述,真正看Demo操作时可能会有疑惑,因为在实现的时候时分为如下三层:Presentation层、Domain层、Data层。其中Domain虽然一般翻译为中间层,因为Presentation层内是通过这一层和Data层建立关系的,但它其实担任的是上图中最核心的部分。如果将这三层作为分别作为单独的模块(Module),它们的依赖关系会是:Data依赖Domain,Presentation依赖Data和Domain。
笔者在安排这三层的内容一般是这样的:
Domain层
1.核心层,不依赖其它层。它只是数据本身。如果说这层还涉及到数据的增删改查工作,也只是逻辑上或者概念上的,具体执行都是由Data层完成的。这层只是提供了若干接口。
2.数据的结构或类型放在这层,例如用户信息类UserEntity。
3.数据之间的相互转换方法在这层,例如提供将String类型转换为UserEntity的方法。
4.其他两层交互的逻辑(UseCase)以及接口在这层。例如从网络中获取用户信息这个逻辑,这个请求一定是由Presentation层发起的,Domain层牵线搭桥,具体执行网络请求的是Data层,并再通过Domain层返回Presentation层。
Presentation层
1.视图层,Android所有Activity、Fragment等等与用户交互的都在这里完成。
2.接收Domain层传来的数据并呈现给用户,将用户操作产生的信息再传会给Domain层。
Data层
1.处理全部数据相关的逻辑,譬如从不同的信息源获取或发送保存信息,信息源可能是网络、数据库,文件,蓝牙等等。
2.Data层实现了Domain层的接口,也即,Domain层对数据的操作最终是Data层完成的。
骨架
上面的内容简述了Clean Architecture的各个层次。这三个层是怎样协作起来的呢?我认为下图是该框架的精髓所在:
访问的信息由上Presentation层经Domain最终到到底Data层,返回的信息反向由底层传至顶层。其中传递的方式当然使用了RxJava以及RxAndroid。Presentation层是数据的订阅者(Subscriber),Data层是数据的被观察者(Observable),二者通过Domain层产生订阅关系。这就是Clean Architecture完成的核心内容:
将UI、业务逻辑、数据分别作为Subscriber、订阅、Observable三者进行拆分
结果就是使每个部分具有低耦合度,可以分别独立开发、测试,同时也提高了各个模块的复用性。
以上内容均代表笔者个人愚见
本文的全部图片引用自https://github.com/android10/Android-CleanArchitecture