我们为什么要把Dagger2,MVP以及Rxjava引入项目中?
2016-11-13 12:19 354 0
Why?(文章最后有惊喜)
我们为什么要把Dagger2,MVP以及Rxjava引入项目中?
-
毫无疑问在Android开发圈中这三个技术是经常被提及的,如此多的文章和开源项目在介绍他们,使用他们,开发者也或多或少的被带动起来在自己的项目中使用他们,但是使用他们之前我们知道为什么要使用他们,他们能给我们带来什么好处吗,还是只是跟随潮流
其实我们大多数项目中是使用不到他们的,或者说对这些技术的需求不是很大,为什么这么说呢？
-
大多数的开发者其实都是在开发功能模块比较少的小项目,对于这些项目来说,其实使用这些技术带来的好处相对于在开发时的所付出的时间来说其实性价比并不高,因为学习这些会有个学习曲线,并且这些技术并不会让你的开发速度加快,相反会让你多写很多代码,比如_MVP_和_Dagger_都会让你多写很多类和接口
-
所以说我们开发小项目根本是感觉不到这些技术给我们带来的好处,也会困惑我们为什么要引入这些技术?
那为什么这些技术会这么火呢？
-
其实这些困惑大多出现在一直做功能模块比较少的小项目的开发者上,只要你做过比较大的项目,随着代码的增多你就会遇到代码的耦合,团队协作时冲突的解决,类依赖的复杂度等问题,其实这些技术就是来解决这些问题的,所以这些技术大项目用的非常多
这些技术出现是为了解决什么？
- 想灵活运用一个技术,必然要了解这些技术为什么出现,出现是为了解决什么问题
MVP
_MVP_的文章很多,我这里就不做过多介绍,我个人的理解就是解耦和扩展以及团队协作,大多数文章都只是介绍了怎么写_MVP_接口,我们不懂为什么用他们,就算会写也只是在做复制粘贴
举个栗子
-
我们需要用户点击按钮从网络获取一段新闻消息显示到_TextView_上,如果都在_Activity_中做这些事情,OK,非常爽,不用多写_MVP_相关的接口和类,啪啪啪一下就写完了
-
但是我们现在需求变了,我们要加入缓存,并且不用_TextView_显示,使用_Toast_显示,现在去改_Activity_,虽然麻烦,但是没问题都是你写的,改改也没问题,但是这个如果不是你写的,你现在去改,要把逻辑重新看一遍,在重新修改之前的代码,如果逻辑一复杂,你重新看一遍逻辑要时间,并且如果改错的话,会影响之前已经写好的功能,这完全违背开闭原则
-
但是我们用_MVP_去开发,就可以缩小这些问题,我们只需要在_Model_层加入缓存逻辑,因为_Presenter_层拿到的是_Model_的接口,他只关心_Model_层返回的数据,至于你的接口是怎么实现的,你的数据是从网络还是数据库还是本地文件获取的,根本不必关心
-
_Presenter_拿到的也是_View_的接口,Presenter_从_Model_获取完数据,返回给_View,就完成了他的工作,他根本不用管_View_是怎么实现的,使用_TextView_显示还是_Toast_显示,这些都是_View_的事情,所以他们每层只用把各自的事情做好根本不用管以外的事情
-
这样我们就可以把_View_,Presenter,_Model_拿给三个不同的人写,需求一变不会影响整个代码,将问题最小化,比如_UI_需求一变我们只用修改_View_层,出了问题可以马上定位,并且易于测试
Dagger
Dagger的门槛个人认为在这三个中是最高的,相关的文章也很多,但是都很多只是告诉你该怎么写这些类,注解该怎么用,很多都没讲为什么不直接_new_,为什么要把如此简单的事情弄这么复杂?其实这还是和项目的大小有关,因为它解决的问题就是大项目的需求
举个栗子
-
我们现在需要一个类叫_Car_,_Car_中需要持有一个叫_People_的对象,_People_中又需要持有_key_对象,Ok,这还不简单
Car car = new Car(new People(new Key()));
但是大型项目的实际情况是这样的
A a = new A();
B b = new B(a);
C c = new C(a,b);
D d = new D(c);
E e = new E(a,b,d);
-
以上只是举个例子,构建一个E,还要构建一堆其他的对象,并且其他对象的构建同样复杂,并且必须按顺序构建,而且需要的对象的生命周期都不一样,有些生命周期可能和_Activity_一样,有些可能是单例,所以在构建的时候还要考虑对象声明周期,考虑对象的来源,在大型项目,这很痛苦,不光用起老火,别人看代码也和看天书一样
-
-
所以这个时候依赖注入框架就派上用场了,我们只用专注于怎么实现功能,对象的依赖关系和生命周期,都让它来帮我们管理,一个_Inject_,它会按照依赖关系帮我们注入我们需要的对象,并且它会管理好每个对象的生命周期,在生命周期还没结束的情况下是不会重复_new_的,所以_Dagger_非常适合大项目,小项目开发者因为项目复杂度低,没遇到这些问题,所以不会理解为什么要用_Dagger_,让简单的_new_,变这么复杂
-
RxJava
提到_Rxjava_最多人都是用来处理,线程调度,回调地狱,加上_Retrofit_又支持_Rxjava_,所以大部分开发者都只会在请求网络和需要切换线程的时候用到_Rxjava_,其实它又一个最重要的特性,它可以让数据的流向更加直观,代码更清晰举个栗子
-
比如说一个庞大的项目,一个事件传递的整个过程可能要经历很多方法,方法套方法,每个方法的位置七零八落,一个个方法跳进去看,跳过去跳过来很容易把脑袋弄晕,不够直观,但是_Rxjava_可以把所有逻辑用链式加闭包的方式呈现,做了哪些操作,谁在前谁在后非常直观,逻辑清晰,维护就会非常轻松,就算不是你写的你也可以很快的了解,你可以把它看作一条河流,整个过程就是对里面的水流做进行加工,懂了这个特性我们才知道在复杂的逻辑中运用_Rxjava_是多么的重要
结语
-
学习新技术,我们不应该盲目的跟风,我们如果不知道这个技术为什么出现,出现是为了解决什么,我也就不知道为什么运用它,我们就算在项目中使用也无法灵活运用,非常浅显的使用,复制粘贴一些模版代码,也根本无法扩展自己的思维
-
这些技术虽然比较适合大项目一点,但是还是建议各位开发者开始使用他们,使用他们能扩展自己的思维,让自己考虑耦合,扩展,团队协作之类大项目才会考虑的问题,你如果一直重复的按最简单的方式写项目,什么都不考虑,你就算是5年经验,也只是以第一年的经验重复5年
-
最后介绍一个将_MVP_,Dagger,Retrofit,Rxjava_等技术相结合并用于快速开发的框架,如果想搭建一个新项目使用这些技术,改了包名就可以直接使用,包含详细的文档,相比于这些技术漫长的学习曲线,我们在实践中学习他们不是更快吗？后面我会写一篇文章,介绍它是怎么将_MVP,_Dagger_相结合并使用到项目中的
Where?
