如何正确执行依赖注入（在Spring中）？[重复]

Question

我对使用Spring向类注入对象有疑问。我在我的项目中使用了这样的代码：

@Resource // or @Autowired even @Inject
private PersonRepository personRepository;

然后通常在以下方法中使用：

personRepository.save(p);

否则，我在Spring示例中发现，注入构造函数：

private final PersonRepository personRepository;

@Autowired
public PersonController(PersonRepository personRepository) {
  this.personRepository = personRepository;
}

所以这两个都是正确的？或者每一个都有它的属性和用法？

Answer 1

从学术上讲，我同意构造函数只是创建对象的更好方法。然而，java bean规范是建立在诱变器的前提上的，以便于反思。围绕这一便利访问范式建立了太多的工具和框架。对于服务、DAO和其他单例场景，我认为只有构造函数注入应该被用作变异器，打破了“只有朋友才能看到你的私密部分”的古老规则。

Answer 2

后者是正确的，这与其说是因为Spring或任何依赖注入容器，不如说是因为面向对象的类设计原则。

应设计类型，以便只能从中创建处于有效状态的实例。为了实现这一点，该类型的所有强制依赖项都需要是构造函数参数。这意味着，可以对这些依赖项进行null-检查，并将其分配给最终字段，以促进不变性。除此之外，在使用代码时，对于该实例的调用方（或创建者），它必须提供哪些依赖项（通过浏览API文档或在IDE中使用代码完成）是显而易见的。

所有这些在场注入中是不可能的。您没有从外部看到依赖关系，您需要一些黑魔法来注入依赖关系，并且您永远无法确定它们是否为空，除非您盲目地信任容器。

最后但并非最不重要的方面实际上是，通过字段注入，向类添加大量依赖项会减少痛苦，这本身就是一个设计问题。构造函数在更早的时候变得更加痛苦，这是一件好事，因为它告诉你一些关于你的类设计的事情：类有太多的责任。首先不需要计算它的指标，当你试图扩展它时，你会感觉到它。

人们经常认为这只是学术上的胡说八道，因为你无论如何都可以依赖容器。以下是我的看法：

>

即使是为容器使用而设计的类型，也将手动使用：在单元测试中。如果你不写单元测试...那就是另一个话题了。

额外构造函数的所谓冗长（“我可以用一行场注入实现同样的事情！！”-“不，你不能。你实际上从多写一行代码中得到了东西。”）可以通过像龙目岛这样的东西来缓解。使用Spring和Lombok注入组件的构造函数如下所示：

@Component
@RequiredArgsConstructor
class MyComponent implements MyComponentInterface {

  private final @NonNull MyDependency dependency;

  …
}

Lombok将负责为每个最终字段生成一个构造函数，并在赋值之前检查给定参数的null。因此，您可以有效地获得字段注入的简洁性和构造函数注入的设计优势。

我最近参加了与一些非Java人的讨论，他们对构造函数DI使用术语“注入”感到非常困惑。实际上，他们认为——这有很多事实——通过构造函数传递依赖根本不是注入，因为这是将对象传递给其他对象的最自然的方式（与任何类型的注入形成鲜明对比）。

也许我们应该为这种风格创造一个不同的术语？也许是依赖喂养？

• 奥利弗·吉尔克-为什么田野注射是邪恶的
• Jens Schauder-一个正确的方法来做依赖注入