查找了很多资料，对于这种开发模式一直有一些迷惑，到底是什么东西让人如此纠结，在这里记录一下自己在编写时遇到的一些问题，加入了一些自己的理解，希望对以后的开发有所帮助；
一，首先配置开发
project的gradle的配置如下图：
project的gradle配置
Module的gradle的配置如下：
Module的gradle配置
2.环境配置好后进行代码编写，在这里首先要对Dagger有一定的了解，下面就先介绍Dagger的相关关键词的含义：
@Inject:通常在需要依赖的地方使用这个注解。换句话说，你用他它告诉Dagger这个类或者字段需要依赖注入。这样，Dagger就会构造一个这个类的实例并满足他们的依赖。
@Module：Modules 类里面的方法专门提供依赖，所以我们定义一个类，用@Module注解，这样Dagger 在构造类的实例的时候，就知道从哪里去找到需要的依赖。modules 的一个重要特征是它们设计为分区并组合在一起（比如说，在我们的APP中可以有多个组成在一起的modules）。
@Provide：在Modules 中，我们定义的方法是用这个注解，以此来告诉Dagger我们想要构造对象并提供这些依赖。
@Component：Components 从根本上来说就是一个注入器，也可以说是@Inject和@Module的桥梁，他的主要作用就是连接这两个部分。Component是可以提供所有定义了的类型的实例，比如：我们必须用@Component注解一个接口然后列出所有的 @Modules组成该组件，如果缺失了任何一个块都会在编译的时候报错。所有的组件都可以通过它的modules知道依赖的范围。
@Scope：Scopes可是非常的有用，Dagger2可以通过自定义注解限定注解作用域，后面会演示一个例子，这是一个非常强大的特点，因为就如前面说的一样，没必要让每个对象都去了解如何管理他们的实例。在scope的例子中，我们用自定义的@PerActivity注解一个类，所以这个对象存活的时间就和activity的一样。简单来说就是我们可以定义所有范围的粒度（@PerFragment,@PerUser,等等）。
Qualifier:当类的类型不足以鉴别一个依赖的时候，我们就可以告诉Dagger我们想要哪种类型的context.
了解了Dagger的关键词以后，我们便可以进行相关的代码编写了。首先可以看一下关于这个模式开发的工程架构。
MVP模式结构
现在来分析下这个工程中是如何使用MVP模式的，其中data是数据来源，也就是MVP中的M,model:实体bean，本来应该放在data中，为了方便查找就抽出来了，毕竟很多地方用到。UI：视图，V和P都在里面，View层比较难组织，可根据个人喜好进行划分，可以按照功能进行划分，也可以按照组件进行划分。下面是dagger2的依赖结构：
dagger2依赖结构
AppComponent通常提供全局的对象以便于其他的组件依赖使用，比如context,rest api接口等，这些都是全局的单例对象。
MainActivityComponent特意针对MainActivity，所以他只提供其对应的MainActivityPresenter,因为其依赖AppComponent,所以它可以使用AppComponent提供的对象。
在这里简要说明一下我自己的理解，这里的MainActivityPresentPresenter就是MVP中的P处理M与V的关联，AppComponent就是@Inject（需要依赖）和@Module,@Provide（提供依赖）的桥梁，MainActivityPresentPresenter通过AppComponent使用Dagger提供的依赖。
AppComponent
可以看到其向外公布了Application,ApiService,User三个对象，供其他component都可以使用
APPComponent 可以看到其向外公布了Application,ApiService,User三个对象，供其他component都可以使用。
APPComponent类
MainActivityComponent
其依赖了AppComponent,本身只提供了MainActivityPresenter,并且只针对MainActivity.
MainActivityComponent类
在MainActivity中的使用：
MainActivity中的使用
从上面的结构可以看到各个模块都清晰的履行着自己的职责让代码结构更清晰。
具体可参考小弟上传到github上的demo：github.com/liuxinggithub/MVP.git
本文参考了网上资料，总结了一下使用方法，方便更多使用者的使用。
网友评论