弹簧再注入概念答案

【问题标题】：Spring re-injection concept弹簧再注入概念
【发布时间】：2014-02-27 05:36:39
【问题描述】：

我刚刚阅读了有关构造函数和设置器依赖注入的 Spring 文档。但是，DI 的整个概念仍然让我很困惑。特别是，这个过程对我来说似乎仍然非常有限或受限。

我理解完全分配和连接对象依赖项的第三方（Spring）的想法。但是如果我们只通过构造函数（init time）和setter（init然后做一些属性设置）来提供依赖，那么我们以后如何重新配置或重新注入新的bean呢？

我的意思是例如 bean A 引用了 bean B。通过构造函数或 setter 注入，我们可以像从文档中知道的那样做。但是，如果稍后在应用程序中我们需要 bean A 来获得对其他对象/bean C 的引用呢？

我们是否需要从新的 Spring XML 配置文件或其他方法加载新的应用程序上下文？此操作可能会执行多次，因此应该易于配置。令我惊讶的一件事是，大多数关于 Spring DI 的教程或解释中都没有提到这样一个常见的任务。也许我需要其他关键字（目前我正在使用 Spring 重新注入）。

【问题讨论】：

【解决方案1】：

可以在A中注入ApplicationContext

private ApplicationContext context;

public void setApplicationContext(ApplicationContect context) {
    this.context = context;
}

那么您将可以随时访问任何 bean

...
    C c =context.getBean(C.class);
...

【讨论】：

【解决方案2】：

无论您在应用程序中的何处需要 ApplicationContext，都可以使用 ApplicationContextAware 接口实现该类。

在这里说

 public class CalenderService implements ApplicationContextAware{

    private ApplicationContext context;//declare this so you can use it

 }

因为它是接口，你需要覆盖它的方法

public void setApplicationContext(ApplicationContext context){
   this.context=context; // here ApplicationContext gets injected.
}

并在任何你想要的地方使用这个上下文。

【讨论】：

【解决方案3】：

Guice、HK2 或 CDI 等上下文驱动框架在注入服务的生命周期与所注入服务的生命周期不同时倾向于使用代理。然后，当代理下的服务发生更改时，代理只会查找新实例并将其用于后续调用。像这样的框架使用代理还有其他原因，例如为了避免具有昂贵初始化成本的服务。

【讨论】：