dagger2从入门到放弃-为何放弃

之前的文章已经将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从入门到放弃-为何放弃)