【问题标题】:Managing complex life cycles in Guice在 Guice 中管理复杂的生命周期
【发布时间】:2016-09-12 03:45:29
【问题描述】:

我遇到了一种情况,我有一个数据对象图,并且想为该图上的每个节点创建一个服务。问题是该服务(及其依赖项)依赖于他们正在工作的节点。像这样的:

class Visitor {

  void enter(Node node){
    Service service = guice.create(node)

    service.doComplexDomainLogic(/*some runtime information about the graph and the path to get here, other things*/)
  }
}

请注意,我的意图是为图表上的每个节点创建Service 实例,以及Service 的任何依赖项的新实例。

所以现在我有几个选择:

  • guice 由辅助注入工厂提供支持。这就是我们目前正在做的事情,如果它们也依赖于node,则需要通过所有服务所依赖的东西来curried对节点的依赖。换句话说,如果我在这里使用辅助注入工厂,我必须为service 所依赖的每个类都使用它,这很讨厌。
  • 我可以使用我们所说的 nested bootstrappers,即带有新注入器的新模块,实际上是一个新环境,在该环境的设置中,我可以编写 bind(Node.class).toInstance(node)。此代码将在第一次访问时执行,并缓存其结果。
  • 我可以使用 guice 的自定义范围(我认为)。

我们在几个地方做了第二个,只是因为我和我的团队不知道自定义范围。我们现在有了自定义作用域的另一种用途,我必须承认它的实现比我想的要复杂得多。关注this guide 会有所帮助,但很明显,我将不得不深入研究线程安全的土地,而我最后一次去那里并不那么愉快。

我应该使用什么 guice 工具来获得这种行为?

【问题讨论】:

  • 你不能为此使用提供者行为/工厂行为吗?你不是注入你的注入器,而是注入一个具有所有必要依赖项的工厂,并使用它来获取你的服务的正确实例?
  • 这就是我们目前正在做的事情,如果Service 依赖于Component,而Component 依赖于Node,那么我需要这样做也为Component 创建一个辅助注入工厂。如果Component 依赖于Utility,等等。这就是我所说的向上“currying”依赖的意思。
  • 哦,对不起-我误解了你的问题

标签: java dependency-injection guice assisted-inject


【解决方案1】:

您可以为您想要的部分注入Injectorcreate a child injector。子注入器将允许您修改对象图并访问所有父注入器的依赖项,但您可以随意访问您的节点。

class Visitor {
  @Inject Injector injector;

  void enter(final Node node) {
    Service service = injector.createChildInjector(new AbstractModule() {
      @Override public void configure() {
        bind(Node.class).toInstance(node);
        // Anything that does require a Node should be bound here, because
        // you can't define it in the parent due to the unsatisfied binding.
        bind(SomeInterface.class).to(SomeClassThatRequiresNode.class);
      }
    }).getInstance(Service.class);

    service.doComplexDomainLogic(/* ... */)
  }
}

虽然可以对范围做类似的事情,但请记住,范围仅用于识别 when to create a new object versus when to return the same object。这意味着您可以创建一个@NodeScoped 范围并确保在处理给定节点时返回相同的对象,但您仍然需要绑定某种@NodeScoped NodeHolder 以在您潜入时保持您的节点。而不是保留并填充这个单独的持有者,子注入器将让您直接请求节点,这可能使您的代码更易于理解和测试。

另见:

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-11-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多