AndroidAndroid开发Android技术知识

Clean Architecture配合MVP使用

2018-04-15  本文已影响309人  tinyfight

概念

Clean架构层级

Clean Architecture中系统最少要分为但不局限于四层:

Clean.jpg

由图可以看出,Clean的依赖规则只能由外向内进行单向依赖。外层的类,方法等不需要被内层知晓。
Clean架构中,最重要的一层是用户实例层(应用业务逻辑层),这一层中我们决定了软件有什么功能, 最终目标是什么, 以及解决了什么现实问题。

Clean+MVP

引用Clean到MVP以后,总共可以分为三个层次:
展示层
领域层
数据层


MVP+Clean.jpg

实现MVP+Clean

实现一个天气展示的Demo App。
创建Android项目。创建两个lib:data和domain。domain建议创建为java library,保证其不会受到污染。
app目录下使用MVP模式进行开发。


Demo.jpg

依赖注入(Dependency Injection)

引入Clean以后,对象的引用和传递将会变得十分繁复,当业务拓展到一定程度,到处的传参将会使代码的层次结构深层化以及降低代码可读性,为了研究一个功能的实现,有时候会需要从上层一直追溯参数到底层,同时又会加剧耦合关系,违背我们的初衷,这是一件很苦恼的事情。
这时候DI则解决了我们的问题,推荐使用Google的Dagger2,Dagger2的原理和使用方式在这里不做赘述。有需要可以看本人的前几篇博客或者自行查阅。

RxJava

推荐使用RxJava(2)做数据流转换以及异步处理。

测试

我们花了这么大代价,搞了个Clean进来,明明很简单的功能,我们却需要大量的类和代码完成,这么做的好处有啥呢(敲代码都敲的手酸没点好处能行?)。
高内聚,低耦合,易维护都是很容易理解的。那么易测试呢?因为各个模块相互独立,耦合性低,特别是对于domain层的纯java业务,剔除了安卓FW的侵入,细分了业务粒度以后,每个业务都可以在单测进行数据mock来测试。

总结

值得注意的是Clean架构能在一定程度上缓解代码耦合的问题,并规定好各个分层领域的职责,但是它并不是银弹,它并不能完全解决开发中App由于业务功能复杂化带来的不可避免的耦合,同时也会在App起初阶段引入Clean会提高代码复杂性和带来多余的累赘类。针对前者我们可以尝试引入更多的例如组件化,模块化等思想来解决,而针对后者,考虑短期性的快速开发,仅仅引入MVP就可以,考虑后期业务的复杂,提前引入也OK,仁者见仁,智者见智。

Demo地址:https://github.com/RemindPan/CleanMVPDemo
水平有限,如有问题,欢迎随时指正。

参考

Android-CleanArchitecture

上一篇 下一篇

猜你喜欢

热点阅读