我是新来的Guice,并试图了解配置()方法在您的模块类的范围。目前下面是我的应用结构。它工作。
class MainClass {
public static void main(String[] args) {
Injector injector = createInjector(new MainModule(param1, param2, param3));
injector = injector.createChildInjector(injector.getInstance(FuncModule.class));
}
}
功能odule.java
class FuncModule extends AbstractModule {
@Override
public void configure() {
// Register a AWS SWF Workflow Worker
// Register a AWS SWF Activity Worker
// Instantiate WorkflowFactory class
TempWorkflowClientExternalFactory obj = new TempWorkflowClientExternalFactoryImpl(<param1>, <param2>);
bind(TempWorkflowClientExternalFactory.class).annotatedWith(Names.named("temp1")).toInstance(obj);
}
}
我试图理解我的配置方法是否做得“太多”。配置方法的意图/范围仅限于绑定吗?如果是这样,在哪里注册工人和实例化工厂对象最好?
您有理由怀疑您的configure
方法是否适合这种类型的初始化;这是判断的问题。Guice确实有这样一句话:模块应该快速且无副作用。
但是Java语言的全部功能是有代价的:在一个模块中很容易做太多的事情。很容易连接到数据库连接或在您的Guice模块中启动HTTP服务器。别这样!在模块中进行重物提升会带来问题:
需要考虑的其他几个因素:
>
Guice只是一个依赖项注入框架,设计为只需要很少的特定于Guice的代码或模式。使用与JSR330兼容的注释(@Inject)和接口(Provider),您应该能够手动复制或替换Guice的功能,或者使用不同的框架(如Spring或Dagger(2))来复制或替换Guice的功能,而无需太多麻烦。然而,Java模块实例是Guice所独有的;如果您想要在非Guice上下文中使用模块中的自定义初始化代码,则需要对其进行重构或重写。这可能是将可重用的初始化代码从Guice模块中分离出来的一个很好的理由。
按照类似的思路,正如Guice wiki所提到的,您应该测试类中的任何非平凡逻辑。没有Guice,Guice模块及其配置
方法很难测试;如果外部构造/配置位于单独的类或方法中,您可能会发现测试它更容易。
当您调用
createInjector
或createChildInjector
以及未指定顺序的所有其他模块时,您在模块的confiure
方法中进行的任何初始化都会发生。这为您提供了非常小的粒度来设置日志记录、服从于后台线程、优雅地捕获异常或控制初始化发生的时间和方式。通过将第三方初始化器代码提取到单独的类或方法,或者提供程序或@提供程序方法,您可以在何时以及如何运行它方面给予自己更多的灵活性。
综上所述,Guice绝对允许实例绑定,并且在模块中经常看到简单轻量级的构造函数调用、初始化器调用和其他实例准备代码。为几行琐碎的初始化创建一个全新的类可能有些过分了。
简言之,保留简单/短/安全的初始化调用,但一旦事情变得复杂/长/危险,就要准备好提取创建或初始化,以给自己更多的控制权。
P. S.另外,尽管从注入器获取模块实例在技术上没有什么问题,但请注意这不是一种常见的模式。充其量,这违反了经验法则,即您在模块
配置
时无法访问运行中的注入器;在最坏的情况下,您可能会发现很难判断您实际调用的是哪个注入器,因此您可以使用哪些绑定...您可以保留它,但要谨慎使用,并考虑通过将父注入器来源的依赖项作为模块构造函数参数传递来保持显式。
/** Injected child module. Get this from a parent injector. */
public class BModule extends AbstractModule {
@Inject Injector injector; // You can always inject the Injector...
@Override public void configure() {
bind(B.class).to(BImpl.class);
}
@Provides C provideC(B b) {
return new C(b);
}
@Provides D provideD() {
return new D(injector.getInstance(B.class)); // but this won't work;
// injector is the parent,
// not the one with this module.
}
}
我试图在步骤定义中使用DI。我有一个模块, 并希望将此实例注入步骤定义的构造函数中。 我想我需要使用cucumber-guice.properties文件来配置GuiceFactory,但是我不知道这是什么?目前我得到的错误是, 我还应该使用提供程序进行构造函数注入吗?
我有一个AssistedInject的问题。我按照这个链接上的说明https://github.com/google/guice/wiki/AssistedInject但是当我运行我的应用程序时,我得到一个错误: 以下是我的模块配置: 这是我的工厂的样子: 接口声明如下: 这是实现 我正在使用dropwizard guice捆绑包。 为什么会发生此错误?
我正在重构一个遗留的Java代码库,以向泽西资源类提供Guice驱动的依赖注入。 这是一个精简的应用程序,它使用传统的Jetty/泽西设置(请参阅 我无法理解各种组件以及它们是如何协同工作的。因此,我不断得到以下错误: 如果我在< code>FooResource的构造函数中直接访问Guice注入器,它就会工作。这告诉我Jetty/Jersey的东西被正确地设置来服务资源,Guice能够正确地构建
主要内容:添加Scope的方式,Google Guice Scope范围 示例,输出Google Guice 每次提供一个值作为其默认行为时都会返回一个新实例。它可以通过Scope范围进行配置。以下是 Google Guice 支持的Scope范围: @Singleton :应用程序生命周期的单个实例。@Singleton 对象需要是线程安全的。 @SessionScoped : Web 应用程序特定会话的单个实例。@SessionScoped 对象需要是线程安全的。 @Requ
问题内容: 我有一个提供这样的JDBI 实例: 在另一个模块中,我想在该DBI实例上调用一些初始化方法(配置对特定数据类型的支持)。放入JDBI模块本身是不合适的逻辑,因为它是特定于应用程序的,而不是使用JDBI的任何应用程序所通用的。我是否可以进行这种“额外”配置? 我尝试使用该方法,但似乎没有为以这种方式提供的对象调用该方法。 问题答案: 该吉斯注射文档描述了如何通过注释与@注入的方法来调用一
问题内容: 我有一个提供这样的JDBI 实例: 在另一个模块中,我想在该DBI实例上调用一些初始化方法(配置对特定数据类型的支持)。放入JDBI模块本身是不合适的逻辑,因为它是特定于应用程序的,而不是使用JDBI的任何应用程序所通用的。我是否可以进行这种“额外”配置? 我尝试使用该方法,但似乎没有为以这种方式提供的对象调用该方法。 问题答案: 该吉斯注射文档描述了如何通过注释与@注入的方法来调用一
问题内容: 对于用Java编写的监视软件,我考虑使用Google Guice作为DI提供程序。项目需要从外部资源(文件或数据库)加载其配置。该应用程序旨在以独立模式或servlet容器运行。 目前,该配置不包含用于依赖项注入的绑定或参数,仅包含某些全局应用程序设置(JDBC连接定义和关联的数据库管理/监视对象)。 我看到两个选择: 使用另一个库,例如Apache Commons Configura
我在Guice3.0下载的任何地方都没有看到Javadoc jar。 是否有一个包含Javadocs的正式jar可用?或者,除了解压缩源文件并将其指向解压缩的文件夹之外,是否还有其他方法将Eclipse指向Javadocs?