Dagger2模块和依赖项之间的区别 [英] Dagger2 difference between modules and dependincies

问题描述

我无法理解告诉组件他的模块是什么以及告诉组件其组件依赖性是什么。

I am failing to understand the difference between telling a component what are his modules and telling the component what are its component dependencies.

例如：

@Module public class ModuleA {
    @Provides DependencyA providesDependencyA() {
        return new DependencyA();
    }
}

@Module public class ModuleB {
    @Provides DependencyB providesDependencyB() {
        return new DependencyB();
    }
}

@Component (modules = {ModuleA.class}) 
public interface ComponentA {
    DependencyA getDependencyA();
}

两者之间有什么区别？

@Component (modules = {ModuleA.class, ModuleB.class}) 
public interface ComponentB {
    DependencyB getDependencyB();
}

并且：

@Component (dependencies = {ComponentA.class}, modules = {ModuleB.class})
public interface ComponentB {
    DependencyB getDependencyB();
}

推荐答案

对于您的简单情况，他们表现大致相同；如果愿意，可以考虑Dagger对组件依赖项的处理，就好像它安装了一个自动生成的模块，该模块将每个 provision方法（零参数工厂方法）包装在具有<$的依赖项上c $ c> @Provides 方法委托给您传入的实例。在两种情况下，Dagger都会生成一个Factory / Provider类实现，委托给您使用的模块/依赖方法。

For your simple case, they behave roughly the same; if you'd like, you can think of Dagger's treatment of component dependencies as though it installs an automatically-generated Module that wraps each provision method (zero-arg factory method) on the dependency with a @Provides method that delegates to the instance you pass in. In either case, Dagger will generate a Factory/Provider class implementation that delegates to the module/dependency method you consume.

但是，还是有一些大的差异，包括：

However, there are some big differences, including these:

• 模块可以采用其他任意形式来自对象图的按方法参数。组件依赖项中的供应方法必须为0-arg。这是最大的区别：组件依赖项是纯外部工厂，而不是对象图中的完整参与者。


• 必须使用 @Provides 供Dagger使用，也允许使用非公开的零参数方法。组件依赖项将每个零零参数方法都视为潜在的提供者。


• 必须使用 @Module 注释模块。组件依赖关系可以是任意类型（不一定只是 @Component 注释的实例），并且无论Dagger是否生成它，您都可以传递任何实现。


• 将检查模块和模块方法的范围；它们必须与附件组件的范围兼容。


• 模块可以是抽象类或接口，可让您使用 @Binds 表示声明性绑定在您的图表中。组件依赖关系是按定义定义的实例，不能访问对象图中的任何内容。


• 当然，模块可以声明其使用的子组件或它们对其他模块的依赖关系。组件依赖关系不能执行任何操作；它们只是外部工厂。


• 如果实例化模块具有零参数公共方法，则不需要在组件构建器中提供它们。甚至必须提供

• Modules can take other arbitrary per-method parameters sourced from your object graph. Provision methods in component dependencies have to be zero-arg. This is the most significant difference: Component dependencies are pure external factories, not full participants in your object graph.
• Module provision methods have to be declared with @Provides for Dagger to consume them, which also allows for non-exposed zero-arg methods. Component dependencies treat every single zero-arg method as a potential provider.
• Modules have to be annotated with @Module. Component dependencies can be arbitrary types (not necessarily just @Component-annotated instances), and you can pass any implementation whether or not Dagger generates it.
• Modules and module methods will have their scopes checked; they must be compatible with the enclosing Component's scope. Component dependencies aren't scope-checked.
• Modules can be abstract classes or interfaces, letting you use @Binds to express declarative bindings within your graph. Component dependencies are instances by definition, and have no access to anything in your object graph.
• Of course, Modules can declare subcomponents they use or their dependencies on other modules. Component dependencies can do neither; they're just external factories.
• Instantiable modules don't need to be supplied in a component builder if they have zero-arg public methods. Component dependencies must be provided, even if you were to provide a concrete type Dagger could instantiate.

简而言之，将模块视为图的配置组件依存关系为图形外部的 。除了上面所述的狭窄重叠之外，对于任何给定的班级，您都应该很清楚地想要扮演哪个角色。

In short, treat modules as configuration of your graph and component dependencies as externs from outside your graph. Other than the narrow overlap you've described above, it should be pretty clear which role you want for any given class.

这篇关于Dagger2模块和依赖项之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！