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

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

调用 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 是最核心的类，至少间接依赖于程序中的所有其他服务。引导时，在您的 main 方法中，您可以调用 applicationContext.getBean("myApplication") 但您不需要在其他任何地方调用 getBean()！

---

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

其他人在您的代码中跟踪服务定位器要容易得多。 IoC 是“神奇的”，但维护程序员必须了解您复杂的 Spring 配置和所有无数的位置，才能弄清楚您是如何连接对象的。 IoC 对于调试配置问题很糟糕。在某些类别的应用程序中，如果配置错误，应用程序将无法启动，并且您可能没有机会逐步了解调试器正在发生的事情。 IoC 主要是基于 XML 的（注解改进了一些东西，但仍然有很多 XML）。这意味着除非开发人员知道 Spring 定义的所有魔术标签，否则他们无法处理您的程序。再懂 Java 还不够好。这会阻碍经验不足的程序员（即，当更简单的解决方案（例如服务定位器）将满足相同的要求时，使用更复杂的解决方案实际上是糟糕的设计）。此外，对诊断 XML 问题的支持远弱于对 Java 问题的支持。依赖注入更适合大型程序。大多数时候，额外的复杂性是不值得的。通常使用 Spring 以防您“以后可能想更改实现”。还有其他方法可以在没有 Spring IoC 的复杂性的情况下实现这一点。对于 Web 应用程序（Java EE WAR），Spring 上下文在编译时有效绑定（除非您希望操作员在爆炸式战争中围绕上下文进行挖掘）。您可以让 Spring 使用属性文件，但使用 servlet 时，属性文件需要位于预先确定的位置，这意味着您不能在同一个盒子上同时部署多个 servlet。您可以使用带有 JNDI 的 Spring 在 servlet 启动时更改属性，但是如果您将 JNDI 用于管理员可修改的参数，则对 Spring 本身的需求会减少（因为 JNDI 实际上是一个服务定位器）。使用 Spring，如果 Spring 正在调度您的方法，您可能会失去程序控制。这很方便，适用于许多类型的应用程序，但不是全部。当您需要在初始化期间创建任务（线程等）或需要 Spring 不知道内容何时绑定到您的 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 的需要，我一直认为这很丑陋。

---

使用 Spring 之类的最酷的好处之一是您不必将对象连接在一起。 Zeus 的脑袋裂开了，你的类出现了，它们的所有依赖项都已根据需要创建和连接。这是神奇而美妙的。

你说的ClassINeed classINeed = (ClassINeed)ApplicationContext.getBean("classINeed");越多，你得到的魔法就越少。更少的代码几乎总是更好。如果你的班级真的需要一个 ClassINeed bean，你为什么不直接把它连线呢？

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

---

动机是编写不明确依赖于 Spring 的代码。这样，如果您选择切换容器，则无需重写任何代码。

将容器视为您的代码不可见的东西，神奇地满足其需求，无需被询问。

依赖注入是“服务定位器”模式的对立面。如果您要按名称查找依赖项，则最好摆脱 DI 容器并使用 JNDI 之类的东西。

---

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

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

只能在您的应用程序中使用一次。

---

Spring 前提之一是避免coupling。定义和使用接口、DI、AOP 并避免使用 ApplicationContext.getBean() :-)

---

这个想法是您依赖依赖注入（inversion of control，或 IoC）。也就是说，您的组件配置了它们需要的组件。这些依赖项是注入的（通过构造函数或设置器）——你自己不会得到。

ApplicationContext.getBean() 要求您在组件中显式命名 bean。相反，通过使用 IoC，您的配置可以确定将使用哪个组件。

这使您可以轻松地使用不同的组件实现重新连接您的应用程序，或者通过提供模拟变体以简单的方式配置对象以进行测试（例如，模拟 DAO，这样您就不会在测试期间访问数据库）

---

其他人已经指出了一般性问题（并且是有效的答案），但我只提供一个额外的评论：这并不是说你永远不应该这样做，而是尽可能少地这样做。

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

---

还有一次使用 getBean 是有意义的。如果您正在重新配置一个已经存在的系统，其中依赖项没有在 spring 上下文文件中显式调用。您可以通过调用 getBean 来启动该过程，这样您就不必一次将其全部连接起来。通过这种方式，您可以慢慢地建立您的弹簧配置，随着时间的推移将每个部件放置到位，并让钻头正确排列。对 getBean 的调用最终将被替换，但是当您了解代码结构或缺少代码结构时，您可以开始连接越来越多的 bean 并使用越来越少的 getBean 调用的过程。

---

原因之一是可测试性。假设你有这个类：

interface HttpLoader {
    String load(String url);
}
interface StringOutput {
    void print(String txt);
}
@Component
class MyBean {
    @Autowired
    MyBean(HttpLoader loader, StringOutput out) {
        out.print(loader.load("http://stackoverflow.com"));
    }
}

你怎么能测试这个bean？比如像这样：

class MyBeanTest {
    public void creatingMyBean_writesStackoverflowPageToOutput() {
        // setup
        String stackOverflowHtml = "dummy";
        StringBuilder result = new StringBuilder();

        // execution
        new MyBean(Collections.singletonMap("https://stackoverflow.com", stackOverflowHtml)::get, result::append);

        // evaluation
        assertEquals(result.toString(), stackOverflowHtml);
    }
}

容易，对吧？

虽然您仍然依赖于 Spring（由于注释），但您可以在不更改任何代码（仅注释定义）的情况下删除对 Spring 的依赖，并且测试开发人员不需要了解 Spring 的工作原理（也许他无论如何都应该知道，但是它允许与 spring 分开审查和测试代码）。

使用 ApplicationContext 时仍然可以这样做。但是，您需要模拟 ApplicationContext 这是一个巨大的界面。您要么需要一个虚拟实现，要么可以使用 Mockito 等模拟框架：

@Component
class MyBean {
    @Autowired
    MyBean(ApplicationContext context) {
        HttpLoader loader = context.getBean(HttpLoader.class);
        StringOutput out = context.getBean(StringOutput.class);

        out.print(loader.load("http://stackoverflow.com"));
    }
}
class MyBeanTest {
    public void creatingMyBean_writesStackoverflowPageToOutput() {
        // setup
        String stackOverflowHtml = "dummy";
        StringBuilder result = new StringBuilder();
        ApplicationContext context = Mockito.mock(ApplicationContext.class);
        Mockito.when(context.getBean(HttpLoader.class))
            .thenReturn(Collections.singletonMap("https://stackoverflow.com", stackOverflowHtml)::get);
        Mockito.when(context.getBean(StringOutput.class)).thenReturn(result::append);

        // execution
        new MyBean(context);

        // evaluation
        assertEquals(result.toString(), stackOverflowHtml);
    }
}

这是很有可能的，但我认为大多数人会同意第一个选项更优雅，并且使测试更简单。

唯一真正有问题的选择是这个：

@Component
class MyBean {
    @Autowired
    MyBean(StringOutput out) {
        out.print(new HttpLoader().load("http://stackoverflow.com"));
    }
}

对此进行测试需要付出巨大的努力，否则您的 bean 将尝试在每个测试中连接到 stackoverflow。一旦你出现网络故障（或者stackoverflow的管理员由于访问率过高而阻止你），你将随机失败测试。

因此，作为结论，我不会说直接使用 ApplicationContext 是自动错误的，应该不惜一切代价避免。但是，如果有更好的选择（并且在大多数情况下都有），那么请使用更好的选择。

---

我只发现了两种需要 getBean() 的情况：

其他人提到在 main() 中使用 getBean() 来获取独立程序的“主”bean。

我对 getBean() 的另一个用途是在交互式用户配置确定特定情况下的 bean 构成的情况下。因此，例如，引导系统的一部分使用带有 scope='prototype' bean 定义的 getBean() 循环通过数据库表，然后设置其他属性。据推测，有一个 UI 可以调整数据库表，这比尝试（重新）编写应用程序上下文 XML 更友好。

---

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

---

您应该使用： ConfigurableApplicationContext 而不是 for ApplicationContext

---