java - 为什么我们不应该使用查找而不是依赖注入(inject)？

Question

是否有任何充分的理由不在应用程序上下文中查找对象而不是“假设”注入(inject)了依赖项？ 例如:

public Dependency getDependency(){
     if (dependency  == null){
        dependency = (Dependency) applicationContext.getBean("dependency");
     }
     return dependency;
}

有争议的论点

使用 Spring 特定对象污染对象

有些人可能会提示使用应用程序上下文会将实现与 Spring 内容绑定(bind)。但是，创建一个 applicationContext 的间接连接可以轻松解决这个问题。好吧...让我举例说明:

public Dependency getDependency(){
     if (dependency  == null){
        dependency = (Dependency) serviceLocator.getBean("dependency");
     }
     return dependency;
}

很难改变实现

首先，它(依赖对象)可以在应用程序上下文中轻松更改。但是，可以使用通常的更改器(mutator)直接插入模拟，甚至更容易:

public void setDependency(Dependency dep){
     this.dependency = dep;
}

历史问题

很久以前，Java 世界中的每个人都在使用服务定位器(在名为 JNDI 的技术的目录服务中)来拥有可互换的对象基础结构。我们可以在目录服务中绑定(bind)三种对象:可序列化数据、引用或 Dircontext。它还允许您在分布式环境中查找对象。

然后，我们有了 Spring 革命，现在大多数情况下都使用 DI(依赖注入(inject))。

但是，Spring 并没有禁止服务定位器模式。例如，使用 ApplicationContext 允许我们以服务定位器的方式查找 bean。我们可以认为 Spring 框架提供了一个具有集中配置的大型对象工厂、依赖注入(inject)工具以及可以轻松处理的服务目录。最后一部分几乎被遗忘了。

相关问题

Why is Spring's ApplicationContext.getBean considered bad?

我不认为这些答案虽然有启发性，但并没有启发上面提出的观点。

Answer 1

我个人对此的看法。 通过注释轻松使用 DI，而不是通过 applicationContext 获取 bean。 但归根结底，我认为主要区别在于依赖项的定位方式。 服务位置需要客户端代码请求相关的特定依赖项，而使用依赖项注入(inject)，容器创建所有对象并将这些依赖项作为构造函数参数注入(inject)。 坦率地说，归根结底，两者都是可行的，但请考虑这一点:据我所知，JNDI 查找在性能方面相当昂贵，因此最终建议您缓存它们。