java - 有没有办法访问之前创建的 Guice 注入(inject)器？

Question

看看 Guice(和 Dagger)的新项目。到目前为止，我看到的每个 Guice 教程都显示在开发人员需要 DI 创建对象实例时创建一个注入(inject)器。

网上看到的一个典型例子:

public static void main(String[] args) {
    Injector injector = Guice.createInjector(new BasicModule());
    Communication comms = injector.getInstance(Communication.class);
}

对我来说，这违背了 DI 的目的 - 在任何需要实例的地方，您都将实例与定义如何构建它的模块联系起来。

有没有办法要求 Guice 创建一个类的实例，该类的模块(依赖关系图)先前已定义给 Guice(例如，在应用程序启动时？)。

我正在使用 Dropwizard.io 框架，因此在某些情况下我无法完全控制类的构造方式，但希望能够模拟我在该类中引用的依赖项。

这同样适用于 Dagger - 我希望能提供其中一个/两者的示例。

编辑:多年来，我在 .NET 中使用过多个 DI 框架，因此我将给出一个示例，说明我正在尝试基于其中一个框架进行的操作。

例如，在 ASP.NET Core DI 实现中，在服务启动时，您可以定义希望 DI 能够创建的服务。通常，您会要求 DI 为您提供一个接口(interface)实现的实例。所以在启动时:

protected override void ConfigureAdditionalServices(IServiceCollection services)
{
    services.AddScoped<ITransactionService, TransactionService>();
}

其中 IServiceCollection 是定义到 DI 的服务集合。

因为 DI 与 ASP.NET 框架集成，从现在起，您通常可以定义一个采用 ITransactionService 的构造函数，DI 将为您提供它。

但是，如果您在不知道的框架中使用 DI，则需要访问当前的 ServiceProvider 实例，然后您可以要求 DI 创建您的对象，如下所示:

var transactionService = ServiceProvider.GetService<ITransactionService>();

我意识到这实现了 Service Locator anti-pattern但它仍然具有将我的代码与具体类实现解耦的好处，并允许我在应用程序启动时模拟它们以进行测试。

回到问题因此，根据这种情况重申我的问题，我如何在代码中的某个随机点向 Guice 请求一个类？

我需要对此代码进行哪些更改才能使其正常工作？

public class TransactionModule extends AbstractModule {
  @Override 
  protected void configure() {
    bind(TransactionServiceBase.class).to(TransactionService.class);
  }
}

// At startup
Injector injector = Guice.createInjector(new TransactionModule());


// Then, somewhere in the application, to get an instance of TransactionService
TransactionServiceBase transactionService = (TransactionServiceBase)Guice.getInstance(TransactionServiceBase.class);

Answer 1

我认为您可能会误解 Injector.getInstance - 就像您的示例有一个 public static 方法来开始工作一样，即使您通常不编写应用程序的其余部分对于所有公共(public)静态方法(我希望)，除了极少数特定情况外，您也不会调用 Injector.getInstance 。

相反，这段代码只是用来让事情顺利进行。另一个流行的“开始使用”是 injector.injectMembers(this) - 让 main() 手动创建一个实例，该实例是应用程序的基础，使用 @Inject-注释的成员，然后只需要求现在创建的注入(inject)器填充成员。

当您继续“向内”访问应用程序的其余部分时，您可能将永远不会再次引用 Injector 实例，而是依赖提供程序、辅助注入(inject)或只是 guice 创建的实例。

这样，您就不必关心注入(inject)器或为其设置的确切模块。在应用程序的整个生命周期中应该只存在一个注入(inject)器(这基本上没有异常(exception)，除非您重新定义了“应用程序”是什么)，并且 99% 的时间它对您隐藏(异常(exception):您的 DI 所在的位置)满足其他一些 DI，并且需要按其类请求某事物的实例，或者您拥有想要内省(introspection)所有声明的绑定(bind)集的工具)。因此，您应该能够只提供 setter、构造函数参数或 init 方法，然后可以手动调用它们，或者让任何 guice 上下文根据自己的特定模块和规则创建它们。