在项目中怎么灵活使用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?

为什么进步太慢,因为你没有一个好习惯

有人问我如何做好架构设计?怎样灵活运用设计模式?我的回答是,你做不好这些只是因为你没有养成一个良好的编程习惯我为什么写这么多开源框架,还长期保持维护?除了我想让更多人受益于开源外,还有一点就是,我想保持我良好的编程习惯写业务代码也可以保持良好的编程习惯啊能,但是太慢!## ...… Continue reading