其动机是编写不显式依赖Spring的代码。这样，如果您选择切换容器，就不必重写任何代码。

把容器想象成代码看不见的东西，神奇地提供它的需要，而不需要被要求。

依赖注入是“服务定位器”模式的对应。如果您打算按名称查找依赖项，那么您也可以摆脱DI容器，使用JNDI之类的东西。

我在另一个问题的评论中提到了这一点，但控制反转的整个思想是让你的任何类都不知道或关心它们如何获得它们所依赖的对象。这使得您可以随时更改所使用的给定依赖项的实现类型。它还使类易于测试，因为您可以提供依赖关系的模拟实现。最后，它使类更简单，更专注于它们的核心职责。

调用ApplicationContext.getBean()不是反转控制!虽然更改为给定bean名配置的实现仍然很容易，但类现在直接依赖Spring提供该依赖项，不能通过其他方式获得它。您不能只是在测试类中创建自己的模拟实现并将其传递给它自己。这基本上违背了Spring作为依赖注入容器的目的。

当你想说:

MyClass myClass = applicationContext.getBean("myClass");

相反，你应该声明一个方法:

public void setMyClass(MyClass myClass) {
   this.myClass = myClass;
}

然后在构型中

<bean id="myClass" class="MyClass">...</bean>

<bean id="myOtherClass" class="MyOtherClass">
   <property name="myClass" ref="myClass"/>
</bean>

Spring会自动将myClass注入到myOtherClass中。

以这种方式声明所有内容，并在其根源上有如下内容:

<bean id="myApplication" class="MyApplication">
   <property name="myCentralClass" ref="myCentralClass"/>
   <property name="myOtherCentralClass" ref="myOtherCentralClass"/>
</bean>

MyApplication是最核心的类，它至少间接地依赖于程序中的所有其他服务。当引导时，在你的主方法中，你可以调用applicationContext.getBean("myApplication")，但你不需要在其他任何地方调用getBean() !

其他人指出了普遍的问题(并且是有效的答案)，但我只想提供一个额外的评论:并不是说你永远不应该这样做，而是尽可能少地做。

通常这意味着它只执行一次:在引导期间。然后，它只是访问“根”bean，通过它可以解决其他依赖关系。这可以是可重用的代码，如基本servlet(如果开发web应用程序)。

选择服务定位器而不是控制反转(IoC)的原因是:

Service Locator is much, much easier for other people to following in your code. IoC is 'magic' but maintenance programmers must understand your convoluted Spring configurations and all the myriad of locations to figure out how you wired your objects. IoC is terrible for debugging configuration problems. In certain classes of applications the application will not start when misconfigured and you may not get a chance to step through what is going on with a debugger. IoC is primarily XML based (Annotations improve things but there is still a lot of XML out there). That means developers can't work on your program unless they know all the magic tags defined by Spring. It is not good enough to know Java anymore. This hinders less experience programmers (ie. it is actually poor design to use a more complicated solution when a simpler solution, such as Service Locator, will fulfill the same requirements). Plus, support for diagnosing XML problems is far weaker than support for Java problems. Dependency injection is more suited to larger programs. Most of the time the additional complexity is not worth it. Often Spring is used in case you "might want to change the implementation later". There are other ways of achieving this without the complexity of Spring IoC. For web applications (Java EE WARs) the Spring context is effectively bound at compile time (unless you want operators to grub around the context in the exploded war). You can make Spring use property files, but with servlets property files will need to be at a pre-determined location, which means you can't deploy multiple servlets of the same time on the same box. You can use Spring with JNDI to change properties at servlet startup time, but if you are using JNDI for administrator-modifiable parameters the need for Spring itself lessens (since JNDI is effectively a Service Locator). With Spring you can lose program Control if Spring is dispatching to your methods. This is convenient and works for many types of applications, but not all. You may need to control program flow when you need to create tasks (threads etc) during initialization or need modifiable resources that Spring didn't know about when the content was bound to your WAR.

Spring非常适合事务管理，并且有一些优点。只是IoC在许多情况下会过度设计，给维护者带来不必要的复杂性。不要在没有考虑不使用IoC的情况下自动使用它。

的确，在application-context.xml中包含该类可以避免使用getBean。然而，即使这样，实际上也是不必要的。如果你正在编写一个独立的应用程序，并且你不想在application-context.xml中包含你的驱动程序类，你可以使用下面的代码让Spring自动装配驱动程序的依赖项:

public class AutowireThisDriver {

    private MySpringBean mySpringBean;    

    public static void main(String[] args) {
       AutowireThisDriver atd = new AutowireThisDriver(); //get instance

       ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
                  "/WEB-INF/applicationContext.xml"); //get Spring context 

       //the magic: auto-wire the instance with all its dependencies:
       ctx.getAutowireCapableBeanFactory().autowireBeanProperties(atd,
                  AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, true);        

       // code that uses mySpringBean ...
       mySpringBean.doStuff() // no need to instantiate - thanks to Spring
    }

    public void setMySpringBean(MySpringBean bean) {
       this.mySpringBean = bean;    
    }
}

当我有一些独立的类需要使用我的应用程序的某些方面(例如测试)时，我需要这样做几次，但我不想将它包含在应用程序上下文中，因为它实际上不是应用程序的一部分。还请注意，这避免了使用字符串名称查找bean的需要，我一直认为这是丑陋的。

使用@Autowired或ApplicationContext.getBean()实际上是一回事。通过这两种方式，您可以获得在您的上下文中配置的bean，并且通过这两种方式，您的代码都依赖于spring。 你唯一应该避免的是实例化你的ApplicationContext。只做一次!换句话说，一条线就像

ApplicationContext context = new ClassPathXmlApplicationContext("AppContext.xml");

在应用程序中只应使用一次。