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

时间：2009-05-01 17:41:25

标签： java spring

我问了一个普通的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说，“使用服务定位器，应用程序类通过向定位器的消息显式地请求它[服务]。注入时没有明确的请求，服务出现在应用程序类中 - 因此控制反转。 控制反转是框架的一个共同特征，但它是有代价的。当您尝试调试时，它往往很难理解并导致问题。所以总的来说，我宁愿避免它[控制反转]，除非我需要它。这并不是说这是一件坏事，只是因为我认为它需要通过更直接的替代方案来证明自己的合理性。“

14 个答案:

答案 0 :(得分：194)

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

调用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()！

答案 1 :(得分：63)

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

  1. 服务定位器让其他人更容易在您的代码中关注。 IoC是“神奇的”，但维护程序员必须了解您的错综复杂的Spring配置以及所有无数的位置，以确定如何连接对象。

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

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

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

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

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

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

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

答案 2 :(得分：25)

在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，我一直认为这很难看。

答案 3 :(得分：21)

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

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

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

答案 4 :(得分：16)

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

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

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

答案 5 :(得分：10)

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

这样的一行 
ApplicationContext context = new ClassPathXmlApplicationContext("AppContext.xml");

只能在您的申请中使用一次。

答案 6 :(得分：4)

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

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

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

答案 7 :(得分：4)

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

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

答案 8 :(得分：4)

Spring的一个前提是避免coupling。定义并使用Interfaces，DI，AOP并避免使用ApplicationContext.getBean（）： - ）

答案 9 :(得分：4)

其中一个原因是可测试性。假设你有这门课程：

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如何工作的任何事情（也许他应该无论如何，它允许分别检查和测试代码与弹簧的作用。

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

答案 10 :(得分：3)

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

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

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

答案 11 :(得分：3)

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

答案 12 :(得分：2)

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

答案 13 :(得分：0)

您应该使用：ConfigurableApplicationContext而不是ApplicationContext

相关问题
最新问题