Spring依赖注入

---

每个基于 Java 的应用程序都有一些对象，它们一起工作以呈现最终用户所看到的工作应用程序。在编写复杂的 Java 应用程序时，应用程序类应尽可能独立于其他 Java 类，以增加重用这些类并在单元测试时独立于其他类进行测试的可能性。依赖注入（有时称为连接）有助于将这些类粘合在一起，同时保持它们的独立性。

假设您有一个具有文本编辑器组件的应用程序，并且您想要提供拼写检查。你的标准代码看起来像这样 -

public class TextEditor {
   private SpellChecker spellChecker;
   
   public TextEditor() {
      spellChecker = new SpellChecker();
   }
}

我们在这里所做的是在文本编辑器和拼写检查器之间创建依赖关系。在控制反转场景中，我们会做这样的事情 -

public class TextEditor {
   private SpellChecker spellChecker;
   
   public TextEditor(SpellChecker spellChecker) {
      this.spellChecker = spellChecker;
   }
}

在这里，文本编辑器不应该担心拼写检查器的实现。SpellChecker 将独立实现，并在 TextEditor 实例化时提供给 TextEditor。整个过程由 Spring 框架控制。

在这里，我们删除了 TextEditor 的完全控制，并将其保留在其他地方（即 XML 配置文件），并且依赖项（即 SpellChecker 类）通过Class Constructor注入到 TextEditor 类中。因此，控制流已被依赖注入（DI）“反转”，因为您已有效地将依赖项委托给某些外部系统。

注入依赖项的第二种方法是通过TextEditor 类的Setter 方法，我们将在其中创建一个 SpellChecker 实例。该实例将用于调用 setter 方法来初始化 TextEditor 的属性。

因此，DI 存在两种主要变体，以下两个子章节将通过示例介绍这两种变体 -

您可以混合使用基于构造函数的 DI 和基于 Setter 的 DI，但最好的经验法则是使用构造函数参数来实现强制依赖项，使用 setter 来实现可选依赖项。

使用 DI 原则，代码更加清晰，并且当对象提供其依赖项时，解耦更加有效。该对象不会查找其依赖项，也不知道依赖项的位置或类，而是一切都由 Spring 框架负责。

基于构造函数的 V/s Setter 基于依赖注入。

基于构造函数和基于 setter 的依赖注入之间几乎没有什么值得注意的区别。

• 粒度控制- 如果构造函数接受多个值，我们需要在 bean 配置期间传递所有值，而在 setter 的情况下，我们可以在特定的 setter 方法中传递值，并且可以保留其他 setter 未配置。

• Setter 覆盖构造函数- 如果同时使用构造函数和基于 setter 的注入，则优先考虑基于 setter 的注入。

• 灵活性- Setter 方法不会像构造函数那样创建新的 bean 实例，并且它们的值也可以更改。