Guice 单例静态注入模式
Guice Singleton Static Injection Pattern
我是 Google Guice 的新手,从概念上理解依赖注入,但 运行 遇到了试图将其合并到我的应用程序中的问题。我的具体问题是围绕单例对象。这是一个例子:
首先,我的模块 class,它将一个沉重的单例连接接口绑定到它的实现。
public class MyModule extends AbstractModule {
@Override
protected void configure() {
bind(Connection.class).to(MyConnection.class).asEagerSingleton();
}
}
现在,在我的主要方法中,我实例化我的应用程序服务器并注入连接:
public class MyApplication {
@Inject
public MyApplication(Connection cxn) {
}
public static void main(String[] args) {
Injector injector = Guice.createInjector(new MyModule());
MyApplication app = injector.getInstance(MyApplication.class);
// Start application, add ShutdownHook, etc...
}
}
到目前为止一切都很好...现在,我有一些利用我的 Connection 对象的 DAO classes,但是使用静态方法检索,如下所示:
public class MyConfiguration {
private Config conf;
private Connection cxn; // Would like to have this injected
private MyConfiguration(Config conf) {
this.conf = conf;
}
public static MyConfiguration getConfig(String name) {
return new MyConfiguration(cxn.getConfig(name));
}
}
我的第一个假设是我会简单地将 @Inject
添加到 cxn
但这不起作用,因为我没有从 Guice 获得实例;它只是给了我一个 NPE。在我看来,我有 2 个选项来获取 Connection 对象:
- 在 MyApplication 中公开一个
getConnection()
方法,基本上遵循 Service Locator Pattern
- 将
requestStaticInjection(MyConfiguration)
添加到 MyModule
我选择了#2,但是 docs say:
This API is not recommended for general use
将我的单身人士提供给需要它的 class 人而不必每次都经过 Injector.getInstance
的最佳做法是什么?我错过了什么?
您错误地考虑了依赖注入。依赖注入和服务定位器是彼此的镜像:使用服务定位器,你向它询问一个对象。使用依赖注入,你不需要去寻找依赖,它们只是交给你。
基本上,"it's turtles all the way down"! 您的 class 拥有的每个 依赖项都应该被注入。如果 MyApplication
需要一个 MyConfiguration
对象,它应该只接受一个 MyConfiguration
对象作为构造函数参数,而不用担心它是如何构造的。
现在,这并不是说您永远不能手动使用 new
-- 但您应该为没有外部依赖性的值类型对象保留它。 (在那些情况下,我认为静态工厂方法通常比 public 构造函数更好,但这不是重点。)
现在有几种方法可以做到这一点。一种方法是将 MyConfiguration
分成许多小块,这样您就可以不用 myConfiguration.getConfig("x")
而是 @Inject @Configuration("x") String
或类似的东西。或者,您可以使 MyConfiguration
本身可注入,然后在其上为片段提供访问器方法。正确的答案在某种程度上取决于您尝试建模的数据类型——使依赖关系过于细化,您的绑定可能变得难以维护(尽管有一些方法可以使它变得更好);使依赖关系过于粗略,使测试变得更加困难(例如:哪个更容易,仅提供您正在测试的 class 需要的 "x" 配置,或构建整个应用程序的配置?) .
你甚至可以两者兼顾:
/** Annotates a configuration value. */
@BindingAnnotation
@Retention(RetentionPolicy.RUNTIME)
public @interface Config {
String value();
}
/** Installs bindings for {@link MyConfiguration}. */
final class MyConfigurationModule extends AbstractModule {
@Override protected void configure() {}
@Provides
@Singleton
MyConfiguration provideMyConfiguration() {
// read MyConfiguration from disk or somewhere
}
@Provides
@Config("x")
String provideX(MyConfiguration config) {
return config.getConfig("x").getName();
}
}
// elsewhere:
/** The main application. */
final class MyApplication {
private final String xConfig;
@Inject MyApplication(@Config("x") String xConfig) {
this.xConfig = xConfig;
}
// ...
}
您可以在单元测试中采用类似的方法:
/** Tests for {@link MyApplication}. */
@RunWith(JUnit4.class)
public final class MyApplicationTest {
// Note that we don't need to construct a full MyConfiguration object here
// since we're providing our own binding, not using MyConfigurationModule.
// Instead, we just bind the pieces that we need for this test.
@Bind @Config("x") String xConfig = "x-configuration-for-test";
@Before public void setUp() {
// See https://github.com/google/guice/wiki/BoundFields
Guice.createInjector(BoundFieldModule.of(this)).injectMembers(this);
}
@Inject MyApplication app;
@Test public void testMyApp() {
// test app here
}
}
依赖注入还鼓励另一种我强烈推荐的最佳实践,即设计您的类型系统,使无效状态不可表示(在最大程度上)。如果 MyApplication
需要的所有配置都在其构造函数中传递,则不可能有一个没有有效配置的 MyApplication
对象。这允许您 "front-load" 您的 class 不变量,这使得推断对象的行为变得容易得多。
最后,关于 Injector.getInstance()
的注释。理想情况下,您只在程序中使用 Injector
一次:在构建后立即使用。也就是说,您应该能够执行 Guice.createInjector(...).getInstance(MyApplication.class).start()
而永远不会在任何地方存储对 Injector
的引用。我倾向于使用 Guava 的 ServiceManager
abstraction (see also this question) 构建应用程序,所以我唯一需要做的就是:
public static void main(String[] args) throws Exception {
Injector injector = Guice.createInjector(...);
ServiceManager manager = injector.getInstance(ServiceManager.class);
manager.startAsync().awaitHealthy();
}
我是 Google Guice 的新手,从概念上理解依赖注入,但 运行 遇到了试图将其合并到我的应用程序中的问题。我的具体问题是围绕单例对象。这是一个例子:
首先,我的模块 class,它将一个沉重的单例连接接口绑定到它的实现。
public class MyModule extends AbstractModule {
@Override
protected void configure() {
bind(Connection.class).to(MyConnection.class).asEagerSingleton();
}
}
现在,在我的主要方法中,我实例化我的应用程序服务器并注入连接:
public class MyApplication {
@Inject
public MyApplication(Connection cxn) {
}
public static void main(String[] args) {
Injector injector = Guice.createInjector(new MyModule());
MyApplication app = injector.getInstance(MyApplication.class);
// Start application, add ShutdownHook, etc...
}
}
到目前为止一切都很好...现在,我有一些利用我的 Connection 对象的 DAO classes,但是使用静态方法检索,如下所示:
public class MyConfiguration {
private Config conf;
private Connection cxn; // Would like to have this injected
private MyConfiguration(Config conf) {
this.conf = conf;
}
public static MyConfiguration getConfig(String name) {
return new MyConfiguration(cxn.getConfig(name));
}
}
我的第一个假设是我会简单地将 @Inject
添加到 cxn
但这不起作用,因为我没有从 Guice 获得实例;它只是给了我一个 NPE。在我看来,我有 2 个选项来获取 Connection 对象:
- 在 MyApplication 中公开一个
getConnection()
方法,基本上遵循 Service Locator Pattern - 将
requestStaticInjection(MyConfiguration)
添加到MyModule
我选择了#2,但是 docs say:
This API is not recommended for general use
将我的单身人士提供给需要它的 class 人而不必每次都经过 Injector.getInstance
的最佳做法是什么?我错过了什么?
您错误地考虑了依赖注入。依赖注入和服务定位器是彼此的镜像:使用服务定位器,你向它询问一个对象。使用依赖注入,你不需要去寻找依赖,它们只是交给你。
基本上,"it's turtles all the way down"! 您的 class 拥有的每个 依赖项都应该被注入。如果 MyApplication
需要一个 MyConfiguration
对象,它应该只接受一个 MyConfiguration
对象作为构造函数参数,而不用担心它是如何构造的。
现在,这并不是说您永远不能手动使用 new
-- 但您应该为没有外部依赖性的值类型对象保留它。 (在那些情况下,我认为静态工厂方法通常比 public 构造函数更好,但这不是重点。)
现在有几种方法可以做到这一点。一种方法是将 MyConfiguration
分成许多小块,这样您就可以不用 myConfiguration.getConfig("x")
而是 @Inject @Configuration("x") String
或类似的东西。或者,您可以使 MyConfiguration
本身可注入,然后在其上为片段提供访问器方法。正确的答案在某种程度上取决于您尝试建模的数据类型——使依赖关系过于细化,您的绑定可能变得难以维护(尽管有一些方法可以使它变得更好);使依赖关系过于粗略,使测试变得更加困难(例如:哪个更容易,仅提供您正在测试的 class 需要的 "x" 配置,或构建整个应用程序的配置?) .
你甚至可以两者兼顾:
/** Annotates a configuration value. */
@BindingAnnotation
@Retention(RetentionPolicy.RUNTIME)
public @interface Config {
String value();
}
/** Installs bindings for {@link MyConfiguration}. */
final class MyConfigurationModule extends AbstractModule {
@Override protected void configure() {}
@Provides
@Singleton
MyConfiguration provideMyConfiguration() {
// read MyConfiguration from disk or somewhere
}
@Provides
@Config("x")
String provideX(MyConfiguration config) {
return config.getConfig("x").getName();
}
}
// elsewhere:
/** The main application. */
final class MyApplication {
private final String xConfig;
@Inject MyApplication(@Config("x") String xConfig) {
this.xConfig = xConfig;
}
// ...
}
您可以在单元测试中采用类似的方法:
/** Tests for {@link MyApplication}. */
@RunWith(JUnit4.class)
public final class MyApplicationTest {
// Note that we don't need to construct a full MyConfiguration object here
// since we're providing our own binding, not using MyConfigurationModule.
// Instead, we just bind the pieces that we need for this test.
@Bind @Config("x") String xConfig = "x-configuration-for-test";
@Before public void setUp() {
// See https://github.com/google/guice/wiki/BoundFields
Guice.createInjector(BoundFieldModule.of(this)).injectMembers(this);
}
@Inject MyApplication app;
@Test public void testMyApp() {
// test app here
}
}
依赖注入还鼓励另一种我强烈推荐的最佳实践,即设计您的类型系统,使无效状态不可表示(在最大程度上)。如果 MyApplication
需要的所有配置都在其构造函数中传递,则不可能有一个没有有效配置的 MyApplication
对象。这允许您 "front-load" 您的 class 不变量,这使得推断对象的行为变得容易得多。
最后,关于 Injector.getInstance()
的注释。理想情况下,您只在程序中使用 Injector
一次:在构建后立即使用。也就是说,您应该能够执行 Guice.createInjector(...).getInstance(MyApplication.class).start()
而永远不会在任何地方存储对 Injector
的引用。我倾向于使用 Guava 的 ServiceManager
abstraction (see also this question) 构建应用程序,所以我唯一需要做的就是:
public static void main(String[] args) throws Exception {
Injector injector = Guice.createInjector(...);
ServiceManager manager = injector.getInstance(ServiceManager.class);
manager.startAsync().awaitHealthy();
}