为什么我们不应该使用查找而不是依赖注入？

Question

是否有充分的理由不在应用程序上下文中查找对象，而不是“假设”注入依赖项？例如：

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

有争议的论点

用Spring特定对象污染对象

有些人可能会抱怨说，使用应用程序上下文会将实现绑定到Spring中。但是，它可以很小的解决创建一个间接的applicationContext。好的..。让我举例说明：

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

难以更改的实现

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

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

历史问题

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

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

然而，Spring并不禁止服务定位器模式。例如，使用ApplicationContext允许我们以服务定位器的方式查找bean。我们可以认为Spring框架提供了一个具有集中配置的对象工厂，即依赖注入工具，但也提供了一个易于处理的服务目录。最后一部分几乎被遗忘了。

相关问题

Why is Spring's ApplicationContext.getBean considered bad?

我不认为这是因为这些答案虽然具有启发性，但并没有启发上述各点。

Answer 1

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

Answer 2

注入服务组件比使用服务定位器的组件更简单，而且简单通常是更好的工程。使用依赖项注入的bean只是普通的旧Java对象，它们(有时)恰好在构造函数上注释了@Inject (Spring可能甚至不需要这些)。bean不需要手动与查找代码接口，而且如果您需要更改要传递给它的依赖项(例如，这样您就可以注入模拟)，那么管理自己的依赖项的bean就需要更多的基础设施来构建。