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

Service Locator is much, much easier for other people to following in your code. IoC is 'magic' but maintenance programmers must understand your convoluted Spring configurations and all the myriad of locations to figure out how you wired your objects. IoC is terrible for debugging configuration problems. In certain classes of applications the application will not start when misconfigured and you may not get a chance to step through what is going on with a debugger. IoC is primarily XML based (Annotations improve things but there is still a lot of XML out there). That means developers can't work on your program unless they know all the magic tags defined by Spring. It is not good enough to know Java anymore. This hinders less experience programmers (ie. it is actually poor design to use a more complicated solution when a simpler solution, such as Service Locator, will fulfill the same requirements). Plus, support for diagnosing XML problems is far weaker than support for Java problems. Dependency injection is more suited to larger programs. Most of the time the additional complexity is not worth it. Often Spring is used in case you "might want to change the implementation later". There are other ways of achieving this without the complexity of Spring IoC. For web applications (Java EE WARs) the Spring context is effectively bound at compile time (unless you want operators to grub around the context in the exploded war). You can make Spring use property files, but with servlets property files will need to be at a pre-determined location, which means you can't deploy multiple servlets of the same time on the same box. You can use Spring with JNDI to change properties at servlet startup time, but if you are using JNDI for administrator-modifiable parameters the need for Spring itself lessens (since JNDI is effectively a Service Locator). With Spring you can lose program Control if Spring is dispatching to your methods. This is convenient and works for many types of applications, but not all. You may need to control program flow when you need to create tasks (threads etc) during initialization or need modifiable resources that Spring didn't know about when the content was bound to your WAR.

Spring非常适合事务管理，并且有一些优点。只是IoC在许多情况下会过度设计，给维护者带来不必要的复杂性。不要在没有考虑不使用IoC的情况下自动使用它。

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

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

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

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

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

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，这是一个巨大的接口。你要么需要一个虚拟的实现，要么你可以使用一个mock框架，比如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是自动错误的，应该不惜一切代价避免。然而，如果有更好的选择(大多数情况下都有)，那么就使用更好的选择。

其他人指出了普遍的问题(并且是有效的答案)，但我只想提供一个额外的评论:并不是说你永远不应该这样做，而是尽可能少地做。

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

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

把容器想象成代码看不见的东西，神奇地提供它的需要，而不需要被要求。

依赖注入是“服务定位器”模式的对应。如果您打算按名称查找依赖项，那么您也可以摆脱DI容器，使用JNDI之类的东西。