之前的文章已经将dagger2的用法大致介绍了一遍,但是最终没有真正在项目中用起来,下面说明下原因
技术原因
项目规模
个人所在公司的项目虽然代码量很大,但是实际上业务代码的层级并不多,而且模块的复用度也不算太高
这种情况下其实依赖注入的思想用的都不多,dagger使用带来的便利有限,比较关键的任务其实是先去细致的梳理业务,分解功能模块这样的工程上解耦,而不是先侧重工具使用
错误提示
错误: 找不到符号
符号: 类 DaggerXXXComponent
位置: 程序包 ...
dagger作为编译期的静态依赖注入框架,大部分时候的编译错误都可以直接定位问题,但是偶尔的类似上面的错误提示就让人非常头疼
没什么有效信息,出错原因也特别多,出错的地方可能跟XXXComponent也隔着十万八千里
静态依赖注入的局限
没有像spring根据一个字符串等动态数据生成一个对象的能力,不过好像android上也没有类似功能的框架
通用性与android的特殊化需求
dagger是一个通用的依赖注入框架,它的目的是代码模块解耦而不是简化android中一些常用代码
所以android中view、点击事件、资源的绑定这些比较特殊化的需求都没有实现
dagger.android带来的限制
dagger.android屏蔽了要注入的组件的Subcomponet,导致继承体系终止了
不过在ContributesAndroidInjector的modules中指定的Module中还可以继续使用ContributesAndroidInjector,使得Activity->Fragment这样常规的Component继承方式还是可以实现
@Module(subcomponents = MvvmComponent.class)
public abstract class MvvmLibActivitiesModule {
@ContributesAndroidInjector(modules = {MvvmLibFragmentModule.class})
abstract MeiziTimerActivity bindFragmentActivity();
}
@Module(subcomponents = MvvmComponent.class)
public abstract class MvvmLibFragmentModule {
@ContributesAndroidInjector(modules = FragmentModule.class)
abstract MeiziTimerFragment bindFragmentActivityFragment();
}
非技术原因
以上列举的原因主要是想说明,dagger使用即使单纯从技术上来看都是有利有弊的,往往使用造成的时间投入并不能带来期望的收益
而更难解决的问题其实是人的问题,如何推进新技术的普遍使用;如何解决因为使用新技术造成的问题;在公司的层面上如何衡量学习使用新技术的成本与收益;如何解决新技术造成招人难或者新手上手难的问题 。这些其实都比技术问题难解决的多
建议
如果是个人项目,dagger可以毫不犹豫的使用,即使坑的自己想骂娘其实也只是耗费一些时间而已,学啥不需要费点工夫呢
如果是创业公司从0开始的项目,要用得自己先有把握能解决好使用过程中的坑,如果你在创建项目的时候还犹豫要不要用dagger,那还是先等等再说
如果是一个成熟的公司项目,除非kpi就是要降低代码耦合度,否则就不要用,即使要用也限定在自己可以掌控的范围内使用(其实大公司能自己掌控的东西并不多),不要痴心妄想可以推进让全组广泛使用
相关文章
dagger2从入门到放弃-概念
dagger2从入门到放弃-最基础的用法介绍
dagger2从入门到放弃-Component的继承体系、局部单例
dagger2从入门到放弃-ActivityMultibindings
dagger2从入门到放弃-dagger.android
dagger2从入门到放弃-其他用法
dagger2从入门到放弃-多模块项目下dagger的使用
dagger2从入门到放弃-为何放弃
示例代码
DaggerInAction
欢迎star
master分支上最新的代码可能会比当前文章的示例代码稍微复杂点,提交记录里包含了每一步的迭代过程,可以顺藤摸瓜
网友评论
关于放弃的理由说的很好。我们公司的项目刚刚完成一次重写,没错不是重构就是重写,使用的Dagger2,感觉瞬间不会写代码了。另外做一些lint优化时,总会报一些Dagger的错误。注解类框架,无论Dagger还是databinding,编译有问题时,总会报一些莫名其妙的错误,导致找不到问题的根源,非常难受。
我比较反对使用这些注解类框架,不是说不好,而是放到团队中使用时,付出跟收益完全不成正比。开发者要花费巨额时间来理清注解的功能代码,就时间成本来说得不偿失。