【问题标题】:Where to keep guice injectors?guice注射器在哪里存放?
【发布时间】:2010-02-01 10:50:50
【问题描述】:

你有什么建议?

我发现最适合我的解决方案 - 将注入器和模块保留在枚举类中。 优点:

  1. 注入器和模块创建一次,
  2. 可以在运行应用程序时从不同的类中使用注入器(不仅在引导时),
  3. 注射器存放在一个地方,很容易找到。

例子:

import static ru.package.Modules.*;

public enum Injectors {

FOO_INJECTOR(BarModule.module()),

FOO2_INJECTOR(FOO_INJECTOR.injector(),
        Bar2Module.module(), FooModule.module());

private final Injector m_injector;

Injectors (Module... modules) {
    m_injector = Guice.createInjector(modules);
}

Injectors (Injector parentInjector, Module... modules) {
    m_injector = parentInjector.createChildInjector(modules);
}

public Injector injector() {
    return m_injector;
}
}

【问题讨论】:

  • 不要这样做。这个策略有很多问题。在您的程序的每次执行中,您的所有注入器都将被创建,无论它们是否需要。

标签: dependency-injection guice


【解决方案1】:

您似乎从根本上误解了依赖注入的工作原理。如果您尝试在代码中除引导应用程序的位置之外的任何位置使用对Injector 的引用,则您没有使用依赖注入,而是将其用作服务定位器。每当你需要测试一个类并且你的类没有在它们的构造函数中明确说明它们的依赖项是什么时,你不得不准备一个Injector(因为谁知道他们会从 Injector 中得到什么?方法,如果他们有或可以获得对它的引用)。实际上,使用您在此处描述的enum 甚至比这更糟糕:您根本无法更改配置,即使是为了测试,因为您的模块被硬编码到枚举中。

使用依赖注入,类只声明它们的依赖并允许Injector透明地工作(在初始调用以获取根应用程序对象之后)提供所有这些依赖。这使得理解、测试和更改代码中的功能相对容易。无论如何,我建议您更多地了解如何使用 DI 和 Guice……您真的不应该这样做。

【讨论】:

  • 我是 DI 和 Guice 的新手,所以请耐心等待) 1)它用于 Web 应用程序,所以我需要在运行时分配具有所有依赖关系图的对象,而不仅仅是在引导程序中。 2)枚​​举。每次要测试时都不应该更改模块。对于测试,您可以配置单独的模块和注入器(如果需要)。 3)为什么我必须只对根对象使用注入器?例如,AOP 呢?
  • @ColinD 我对注入器也有类似的需求,因为我不仅需要在构建期间进行 DI,而且还希望能够在运行时访问 Singleton 实例(通过 Beanshell 进行运行时调试目的等)。换句话说,我需要某种类型的单例注册表。现在,如果没有 DI,我们通常会使用静态 final 字段来保存它,但现在有了 Guice DI,注入器似乎是注册表的自然选择。
  • 考虑遗留应用程序,在这些应用程序中,立即在依赖关系图中的任何地方应用依赖注入可能是不切实际的。当您尝试一点一点地引入依赖注入时,您最终会使用注入器作为服务定位器,战略性地放置。
  • @beluchin:这是合理的,前提是您首先了解依赖注入的使用方式,并在可能的情况下以这种方式使用它。
【解决方案2】:

更大的问题是为什么?

应该没有必要保留Injector,因为一旦注入完成,Injector 应该完成并且应该消失。

但是,如果你真的需要Injector,你不能简单地:

@Inject
private Injector injector;

这个应用程序是基于网络的还是独立的?

【讨论】:

  • 此代码也用于网络,但不仅限于此。关于注入注射器我已经问过问题:stackoverflow.com/questions/2176216/how-to-inject-injector。问题是 guice 不允许绑定或提供 Injector。
  • 我必须同意 ColinD,了解 DI 的工作原理可能很有用。这将为您节省大量时间和精力:)
猜你喜欢
  • 2012-07-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-05-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多