Spring依赖注入

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

假设您有一个包含文本编辑器组件的应用程序，并且您想提供拼写检查功能。您的标准代码如下所示：

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

我们在这里所做的是，在TextEditor和SpellChecker之间创建依赖关系。在控制反转方案中，我们将改为执行以下操作：

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

在这里，TextEditor不必担心SpellChecker的实现。SpellChecker将独立实现，并在TextEditor实例化时提供给TextEditor。整个过程由Spring框架控制。

在这里，我们移除了TextEditor的全部控制权，并将其放在其他地方（即XML配置文件），并且依赖项（即类SpellChecker）通过**类构造器**注入到类TextEditor中。因此，控制流已通过依赖注入 (DI)“反转”，因为您已有效地将依赖项委托给某个外部系统。

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

因此，DI存在两种主要变体，接下来的两个子章节将分别用示例介绍它们：

您可以混合使用基于构造器和基于Setter的DI，但一个好的经验法则是对强制依赖项使用构造器参数，对可选依赖项使用setter。

使用DI原则，代码更简洁，当向对象提供其依赖项时，解耦更有效。对象不查找其依赖项，也不了解依赖项的位置或类，而是Spring框架处理所有这些。

基于构造器与基于Setter的依赖注入。

基于构造器和基于Setter的依赖注入之间存在一些值得注意的差异。

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

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

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