在项目中怎么灵活使用Dagger?

Reading time ~1 minute

前言

最近介绍Dagger的文章挺多的,大多介绍的都是用法和注解的意义,在附带一个小Demo,把刚学习的开发者看的云里雾里的,看完还是不知道怎么结合在项目中使用?什么时候在项目中用?在项目中的使用场景是什么?

架构图

这是本人写的MVP+Dagger框架MVPArms的架构图,通过Dagger来为MVP提供所需要的一切类和接口,本框架的初衷是让开发者更好的学习及使用此类开发模式,如果不理解为什么要使用MVP+Dagger来开发项目,可以先看这篇文章

对比

之前我看了几个使用MVP+Dagger+Retrofit开发,并且有一定star量的开源项目,所以对比了下我的框架,有以下几点:

1.使用Dagger的场景太少了,大部分只是使用Dagger注入MVP类,并且有些Retrofit都是自己new,并没有使用Dagger管理,甚至有些使用一次接口就retrofit.create(ApiService.class)一次,这个本可以使用Dagger将它作为单例来调用的

2.有一些设计的ComponentModule完全只是用来注入Activity和一些单例


@ActivityScope
@Component(modules = {ActivityModule.class},dependencies = {AppComponent.class})
public interface ActivityComponent {
    void inject(AActivity activity);
    void inject(BActivity activity);
    void inject(CActivity activity);
    ...
}

只要多一个Activity,他就可以一直重载inject方法,于是就可以用一组component,module来为所有Activity注入,但是如果遇到Activity需要临时注入一些其他的组件,并且每个Activity要注入的组件都不一样,就没办法了,缺少灵活性

3.还是和第2条有关,如果只有一个Module,Dagger就无法根据每个Presenter的需要,提供多个不同的Model,比如这个Presenter使用过这个接口,并且缓存已经在Model中写好,其他Presenter如果也要用到这个接口,就可以直接重用这个Model,MVP最大的好处之一就是可以重用MP

4.有些没有Model层,直接给Presenter注入Retrofit Api(有些是注入一个管理类,如果项目小接口少,这样还不错,但是有没有想过项目一大,接口一多里面就非常混乱),所有网络请求逻辑在Presenter中,如果现在需求变了,需要加入缓存,就需要更改Presenter的逻辑,这样就可能影响一些和这个功能无关的逻辑,如果有Model层,里面持有请求网络和缓存的功能类,这样Presenter就不需要管,数据是从网络还是数据库获取的,Model层只用保证返回给Presenter的数据无误,而Presenter只用专注于逻辑,这样各自只用保证各自的职责,屏蔽细节,易扩展,出错也好定位

如何用?

在项目中用到最多的就是向Presenter提供ViewModel的同时,在向每一层提供所需要的单例类,并且使用Dagger不断的重用PresenterModel,其实Dagger本来就抽象,说再多不如直接看代码是怎么实现的,然后照着模版直接在自己项目中使用,本文的主题不就是在项目中怎么灵活使用Dagger吗?那就直接在项目中找答案不是更快?

Launch?

MVPArms官方首发一键生成组件化,体验纯傻瓜式组件化开发

# 前言我在 [上篇文章](https://www.jianshu.com/p/f671dd76868f) 中介绍了 [MVPArms](https://github.com/JessYanCoding/MVPArms/wiki) 的官方快速组件化方案 [ArmsCompo...… Continue reading