为什么Spring的ApplicationContext.getBean被认为是坏的？

13 回答

• 10

  使用像Spring这样的东西最酷的好处之一就是你不必将对象连接在一起 . Zeus的头部分开，你的类出现了，完全形成了所有依赖关系，根据需要创建和接线 . 这是神奇而奇妙的 .

  你说的越多 ClassINeed classINeed = (ClassINeed)ApplicationContext.getBean("classINeed"); ，你只需将它连接起来就不那么神奇了吗？

  也就是说，显然需要创建第一个对象 . 你的main方法通过getBean（）获取一两个bean没有任何问题，但是你应该避免它，因为每当你使用它时，你并没有真正使用Spring的所有魔法 .

  回复于 2024-04-20T17:18:29+08:00
• 4

  我只发现了两种需要getBean（）的情况：

  其他人提到在main（）中使用getBean（）来获取独立程序的“main”bean .

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

  回复于 2024-04-20T17:18:29+08:00
• 3

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

  回复于 2024-04-20T17:18:29+08:00
• 25

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

  调用 ApplicationContext.getBean() 不是控制反转！虽然它以任何其他方式得到它 . 您可以't just make your own mock implementation in a test class and pass that to it yourself. This basically defeats 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() ！

  回复于 2024-04-20T17:18:29+08:00
• 57

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

  回复于 2024-04-20T17:18:29+08:00
• 3

  Spring的一个前提是避免coupling . 定义和使用接口，DI，AOP并避免使用ApplicationContext.getBean（）:-)

  回复于 2024-04-20T17:18:29+08:00
• 3

  确实，在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;    
      }
  }
  

  当我有一些需要使用我的应用程序的某些方面（例如用于测试）的独立类时，我需要这样做几次，但我不想将它包含在应用程序上下文中，因为它不是实际上是应用的一部分 . 另请注意，这避免了使用String名称查找bean的需要，我一直认为这很难看 .

  回复于 2024-04-20T17:18:29+08:00
• 16

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

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

  应该只在您的应用程序中使用一次 .

  回复于 2024-04-20T17:18:29+08:00
• 182

  更喜欢服务定位器而不是控制反转（IoC）的原因是：

  • 服务定位器让其他人更容易在您的代码中跟踪 . IoC是“神奇的”，但维护程序员必须了解您的复杂Spring配置和所有无数的位置，以弄清楚如何连接对象 .

  • IoC很难调试配置问题 . 在某些类别的应用程序中，如果配置错误，应用程序将无法启动，您可能无法逐步完成调试器的操作 .

  • IoC主要基于XML（Annotations改进了一些东西，但仍有很多XML） . 这意味着开发人员无法处理您的程序，除非他们知道Spring定义的所有魔术标记 . 再也不懂Java了 . 这阻碍了经验较少的程序员（即，当更简单的解决方案，例如服务定位器，将满足相同的要求时，使用更复杂的解决方案实际上是糟糕的设计） . 此外，对诊断XML问题的支持远远弱于对Java问题的支持 .

  • 依赖注入更适合大型程序 . 大多数情况下，额外的复杂性是不值得的 .

  • 通常使用Spring以防“以后可能想要更改实现” . 如果没有Spring IoC的复杂性，还有其他方法可以实现这一目标 .

  • 对于Web应用程序（Java EE WAR），Spring上下文在编译时被有效约束（除非您希望运算符在爆炸的战争中围绕上下文进行grub） . 您可以使Spring使用属性文件，但是使用servlet属性文件需要位于预定位置，这意味着您无法在同一个盒子上同时部署多个servlet . 您可以使用Spring和JNDI在servlet启动时更改属性，但如果您使用JNDI作为管理员可修改的参数，则Spring本身的需求会减少（因为JNDI实际上是一个服务定位器） .

  • 使用Spring，如果Spring调度到您的方法，您可能会丢失程序控制 . 这很方便，适用于许多类型的应用程序，但不是全部 . 当您需要在初始化期间创建任务（线程等）时，您可能需要控制程序流，或者需要可修改的资源，Spring在内容绑定到WAR时不知道这些资源 .

  Spring非常适合事务管理并具有一些优势 . 只是IoC在许多情况下可能过度工程化并为维护者带来无根据的复杂性 . 不考虑先不使用IoC的方法，不要自动使用IoC .

  回复于 2024-04-20T17:18:29+08:00
• 2

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

  通常这意味着它只完成一次：在引导过程中 . 然后它只是访问“root”bean，通过它可以解析其他依赖项 . 这可以是可重用的代码，如基本servlet（如果开发Web应用程序） .

  回复于 2024-04-20T17:18:29+08:00
• 3

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

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

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

  回复于 2024-04-20T17:18:29+08:00
• 4

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

  把容器想象成代码看不见的东西，神奇地满足它的需要，而不被问到 .

  依赖注入是“服务定位器”模式的对应点 . 如果您要按名称查找依赖项，您可以删除DI容器并使用类似JNDI的东西 .

  回复于 2024-04-20T17:18:29+08:00
• 19

  其中一个原因是可测试性 . 说你有这个班：

  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 是自动错误的，应该不惜一切代价避免 . 但是，如果有更好的选择（并且在大多数情况下），那么使用更好的选项 .

  回复于 2024-04-20T17:18:29+08:00