春季的Setter DI和Constructor DI？

Question

Spring有两种类型的DI: setter和construction。

基于构造函数的DI修复了需要注入依赖项的顺序。基于Setter的DI不提供此功能。

基于Setter的DI帮助我们只在需要时注入依赖项，而不是在构建时要求它。

我没有看到任何其他显著的差异，因为两种类型的Spring都提供了相同的特性--在代码启动时，setter和构造函数DI都注入了依赖项。当然，构造函数DI将通过构造函数执行，而setter DI将在构造对象之后通过setter完成，但在性能等方面对开发人员没有任何影响。这两种方法都提供了指定依赖注入顺序的方法。

--我正在寻找一种场景，其中一种比另一种提供了明显的优势，或者一种类型完全不可用。

Answer 1

当涉及到Spring特定的利弊时：

• 构造函数注入(从定义中)不允许在bean之间创建循环依赖关系。这个限制实际上是构造函数注入的一个优点--当使用setter注入时，Spring可以解决循环依赖关系，而您甚至没有注意到。
• 另一方面，如果使用构造函数注入，CGLIB无法创建代理，迫使您要么使用基于接口的代理，要么使用虚拟的无arg构造函数。请参阅：SPR-3150

Answer 2

您应该根据设计考虑作出决定，而不是工具(Spring)考虑。不幸的是，Spring培训我们使用setter注入，因为在最初构思它时，Java中没有所谓的“注释”，而在XML中，setter注入工作并且看起来要好得多。今天，我们从这些约束中解脱出来，从而允许它再次成为一个设计决策。bean应该对bean和setter注入所需的任何依赖项使用构造函数注入，这些依赖项是可选的，并且具有合理的缺省值，这或多或少是OOD从一开始就告诉我们的。

Answer 3

构造器注入：我们正在通过构造函数注入依赖项。

通常，我们可以使用强制依赖关系.。

如果使用构造函数注入，则有一个称为“循环依赖”的缺点.

循环依赖关系：假设A和B.A依赖于B，B依赖于A，在此构造函数注入将失败。在那个时候，Setter注入是有用的。

如果对象状态不是不一致的，它就不会创建对象。

设置注入：我们正在通过Setter方法注入依赖项。

这对于非强制性依赖关系很有用.

可以使用设置注入重新注入依赖关系。在构造器注入中是不可能的。