在项目中怎么灵活使用Dagger?
2016-12-23 14:41 378 0
前言
最近介绍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. 有一些设计的Component和Module完全只是用来注入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最大的好处之一就是可以重用M和P层
4. 有些没有Model层,直接给Presenter注入Retrofit Api(有些是注入一个管理类,如果项目小接口少,这样还不错,但是有没有想过项目一大,接口一多里面就非常混乱),所有网络请求逻辑在Presenter中,如果现在需求变了,需要加入缓存,就需要更改Presenter的逻辑,这样就可能影响一些和这个功能无关的逻辑,如果有Model层,里面持有请求网络和缓存的功能类,这样Presenter就不需要管,数据是从网络还是数据库获取的,Model层只用保证返回给Presenter的数据无误,而Presenter只用专注于逻辑,这样各自只用保证各自的职责,屏蔽细节,易扩展,出错也好定位
如何用?
在项目中用到最多的就是向Presenter提供View和Model的同时,在向每一层提供所需要的单例类,并且使用Dagger不断的重用Presenter和Model,其实Dagger本来就抽象,说再多不如直接看代码是怎么实现的,然后照着模版直接在自己项目中使用,本文的主题不就是在项目中怎么灵活使用Dagger吗?那就直接在项目中找答案不是更快?
