为什么在 Spring Application 中应该避免 getBean()

Question

我正在浏览 spring 文档，并遇到了以下声明-

然后，您可以使用 getBean 来检索 bean 的实例。 ApplicationContext 接口还有一些其他方法 检索 bean，但理想情况下，您的应用程序代码不应该使用 他们。 确实，您的应用程序代码不应调用 getBean() 方法，因此不依赖于 Spring API 全部。例如，Spring 与 Web 框架的集成提供了 各种 Web 框架组件的依赖注入，例如 控制器和 JSF 管理的 bean，允许您声明一个 通过元数据对特定 bean 的依赖（例如，自动装配 注释）。

参考-https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html

在我的应用程序中，我收到一些参数给我的客户端方法，基于这些参数，我注入了接口的正确实现。 我这样做的方式是，在连接这些参数后搜索 bean id。 例如，如果我收到type=C、subType=D，我会通过调用 getBean(beanId) 获得带有bean id=typeCsubTypeD 的 bean。 即，我的依赖项是在运行时决定的。

我已经通过Why is Spring's ApplicationContext.getBean considered bad?

但是，这不包括我的用例（正如该问题中的评论所解决的那样）。

Answer 1

一般来说，我的建议是避免当月口味狂热者。

现在，控制反转是炒作（作为SOLID设计原则的一部分），所以如果有人使用任何违反该原则的东西，人们会盲目地抨击它并说你应该避免使用它。然而，真正的答案是在软件设计方面没有普遍的规律。如果您有正当理由不在应用程序中使用控制反转，那么使用getBean() 肯定没问题。该原则通常意味着的意思是“不要在可以使用控制反转的静态初始化上下文中使用getBean()”。

例如，我们有一个使用 Spring 作为“bean 脚本语言”的应用程序，允许非开发人员在不使用成熟的 DSL 的情况下定义可配置的 Java bean。如果您在这方面使用 Spring，那么没有合理的方法可以避免使用 getBean()。