使用Spring之类的东西的一个最酷的好处是，您不必将对象连接在一起。Zeus的头部打开，您的类就出现了，并且根据需要创建并连接了它们的所有依赖项。这是神奇的和奇妙的。

你越是说ClassINeed ClassINeed = (ClassINeed)ApplicationContext.getBean(" ClassINeed ");，你得到的魔法就越少。代码越少越好。如果您的类确实需要ClassINeed bean，为什么不直接将它连接进来呢?

也就是说，显然需要创建第一个对象。主方法通过getBean()获取一两个bean并没有什么问题，但是应该避免使用它，因为无论何时使用它，都没有真正使用Spring的所有魔力。

其思想是依赖于依赖注入(控制反转，IoC)。也就是说，您的组件已经配置了所需的组件。这些依赖关系是注入的(通过构造函数或设置函数)——你不能自己得到。

getbean()要求您在组件中显式地命名bean。相反，通过使用IoC，您的配置可以确定将使用什么组件。

这让你可以轻松地用不同的组件实现重新连接应用程序，或者通过提供模拟变量(例如，模拟DAO，这样你就不会在测试期间碰到数据库)以一种直接的方式配置测试对象。

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

调用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() !

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

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

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

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

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

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

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

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