java - 为什么 Spring 的 ApplicationContext.getBean 被认为不好？

Question

我问了一个一般的 Spring 问题:Auto-cast Spring Beans并且有多个人回应说应该尽可能避免调用 Spring 的 ApplicationContext.getBean()。这是为什么？

我还应该如何访问我配置 Spring 来创建的 bean？

我在非 Web 应用程序中使用 Spring，并计划访问共享 ApplicationContext 对象 as described by LiorH .

修正

我接受下面的答案，但这里是 Martin Fowler 的另一种看法，他 discusses the merits of Dependency Injection vs. using a Service Locator (这本质上与调用包装的 ApplicationContext.getBean() 相同)。

部分，Fowler 说，“使用服务定位器，应用程序类通过向定位器发送消息明确地要求它[服务]。通过注入(inject)没有明确的请求，服务出现在应用程序类中 -因此控制反转。控制反转是框架的一个共同特征，但它是有代价的。当您尝试调试时，它往往难以理解并导致问题。所以总的来说，除非我需要它，否则我更愿意避免它[控制反转]。这并不是说这是一件坏事，只是我认为它需要证明自己比更直接的选择更合理。"

Answer 1

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

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

你想说的任何地方:

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 注入(inject) myOtherClass。

以这种方式声明所有内容，并且在其根源上都有类似的内容:

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

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