Spring的前提之一是避免耦合。定义和使用接口，DI, AOP，避免使用ApplicationContext.getBean():-)

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

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

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

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

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

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

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

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

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

但是，仍然有一些情况需要使用服务定位器模式。 例如，我有一个控制器bean，这个控制器可能有一些默认的服务bean，这些服务bean可以通过配置注入依赖项。 虽然这个控制器现在或以后还可以调用许多附加的或新的服务，但这些服务需要服务定位器来检索服务bean。

There is another time when using getBean makes sense. If you're reconfiguring a system that already exists, where the dependencies are not explicitly called out in spring context files. You can start the process by putting in calls to getBean, so that you don't have to wire it all up at once. This way you can slowly build up your spring configuration putting each piece in place over time and getting the bits lined up properly. The calls to getBean will eventually be replaced, but as you understand the structure of the code, or lack there of, you can start the process of wiring more and more beans and using fewer and fewer calls to getBean.