就像上面的标题一样，我对直接通过@Autowired注解注入ApplicationContext还是在一个单例的spring bean中实现ApplicationContextAware接口的利弊感到困惑。
在哪些情况下，你更喜欢哪一种，为什么？谢谢。
其实，这两种方式都不好。它们都将你的应用与Spring框架捆绑在一起，从而颠覆了整个反转控制的概念。在一个理想的世界里，你的应用程序根本不应该意识到被ApplicationContext管理。
一旦你选择了违反这个原则，你怎么做并不重要。ApplicationContextAware 是一直存在的传统版本 至少从2.0版本开始. @Autowired 是一个较新的机制，但他们的工作方式几乎是一样的。我可能会选择 ApplicationContextAware，因为它在语义上明确了它的内容。
正如 @Sean Patrick Floyd 所说，ApplicationContext 的需求往往是由于一个糟糕的设计。但有时你没有其他选择。在这些情况下，我更喜欢使用@Autowired，因为这是我注入所有其他属性的方式。那么，如果我使用@Autowired来注入MyRepository，为什么我不能用它来注入ApplicationContext或任何其他Spring Bean呢？
我只使用Spring接口来做那些我无法用注解来做的事情，例如BeanNameAware。
如果你需要在一个单体中获得一个原型，那么你可以使用方法注入。基本上，你创建一个抽象方法，返回你需要的对象，每次调用该方法时，spring都会返回原型。你在你的spring配置中定义 "lookup-method"。这里有一些链接。http:/docs.spring.iospringdocs1.2.9referencebeans.html#beans-factory-method-injection。http:/java.dzone.comarticlesmethod-injection-spring。
既然你是 不扩展任何spring类，你的应用程序总是与框架分离。. 大多数情况下，你将不希望注入的。ApplicationContext 中定义的豆子，但需要注入在 ApplicationContext.
最好的情况是始终坚持最低限度的要求，除非你有任何特定的要求，这对弹簧来说非常简单。
所以要么,
注释你的豆子和 scan 他们 application context，然后用 @Autowire 来连接它们。
使用 application context 来连接你的Bean权宜之计(旧的xml风格配置)。你可以使用 @Autowire 也用这种方法。
当你想控制bean的生命周期时，你可以读取API，并对其进行定制，但大多数时候，这些一般的设置就可以完成工作了。
下面是一些例子。
没有必要使用 ApplicationContext 根本没有。
如果你需要在单人Bean中使用原型范围的Bean，注入一个 org.springframework.beans.factory.ObjectFactory.例如使用构造函数注入。
@Service
class MyClass {
private ObjectFactory<MyDependency> myDependencyFactory;
public MyClass(ObjectFactory<MyDependency> prototypeFactory) {
myDependencyFactory = prototypeFactory;
}
}
现在有什么好处，比使用 ApplicationContext 你可以通过简单地传递一个lambda来替代这个依赖关系（例如在测试中）。ObjectFactory 是一个 @FunctionalInterface)，返回它的存根版本。
虽然它可以存根于 ApplicationContext，在这种情况下，不清楚哪些豆子会被查到，需要被支取。