浅谈spring DI 依赖注入方式和区别

spring DI

Spring框架对Java开发的重要性不言而喻，其核心特性就是IOC（Inversion of Control， 控制反转）和AOP，平时使用最多的就是其中的IOC，我们通过将组件交由Spring的IOC容器管理，将对象的依赖关系由Spring控制，避免硬编码所造成的过度程序耦合。

3种DI注解的区别

1 @Autowired

使用特点

• Autowired注解是spring框架提供的
• Autowired注解优先byType获取java bean，其次byName
• Autowired注解配合Qualifier注解区分java bean的名称，主要用于同一个类型的javabean有多个实
• Autowired注解注入的对象，一般要求非null，如果允许为null，需要required=false属性声明
• @Autowired可以作用在变量、setter方法、构造函数上

使用过程

a、 将@autowored写在被注入的成员变量上，就不用再xml文件中配置了，在程序中去掉相应的setter和getter方法，

b、 还可以写在构造方法上、setter方法上

c、@Qualifier
@Qualifier("XXX") 中的 XX是 Bean 的名称，所以 @Autowired 和 @Qualifier 结合使用时，自动注入的策略就从 byType 转变成 byName 了。
不过需要注意的是@Autowired 可以对成员变量、方法以及构造函数进行注释，而 @Qualifier 的标注对象是成员变量、方法入参、构造函数入参。

2 @Inject

使用特点

• @Inject是JSR330 (Dependency Injection for Java)中的规范，需要导入javax.inject.Inject; 实现注入
• @Inject是根据类型进行自动装配的，如果需要按名称进行装配，则需要配合@Named
• @Inject可以作用在变量、setter方法、构造函数上
• 与@Autowired使用类似，想比之下，采用spring提供的@Autowired更为普遍

使用过程
a、 将@Inject可以作用在变量、setter方法、构造函数上，和@Autowired一样

b、@Named
@Named("XXX") 中的 XX是 Bean 的名称，所以 @Inject和 @Named结合使用时，自动注入的策略就从 byType 转变成 byName 了。

3 @Resource

使用特点

• esource注解是jdk提供的，属于j2ee规范
• Resource注解优先byname获取java bean，其次byType
• Resource注解的属性名称作为java bean的名称进行查找，如果有name参数，则使用name参数查找java bean
• Resource注解如果声明了name属性，则必须按照name查找对象，不会再使用类型查找
• @Resource可以作用在变量、setter方法上

使用过程
a、@Resource实例

3种注入方式的区别

注意项

• 注入方式：field注入、setter注入与构造器注入
• spring推荐使用setter方法和构造器注入Autowired的bean对象，因此IDEA等工具中私有属性使用Autowired注入会提示警告。setter方法和构造器注入的方式，可以让对象不依赖于spring而独立使用，更加灵活；私有属性则只能通过spring上下文自动注入，一旦注入失败，没有重新注入的方式。
• @Resource不能用于构造器注入

1 field注入

@Controller
public class FooController {
  @Autowired
  //@Inject
  private FooService fooService;
  
  //简单的使用例子，下同
  public List<Foo> listFoo() {
      return fooService.list();
  }
}

这种注入方式应该是最常见的注入方式。原因很简单：

• 注入方式简单：加入要注入的字段，附上@Autowired，即可完成。
• 使得整体代码简洁明了，看起来美观大方。

2 构造器注入

@Controller
public class FooController {
  
  private final FooService fooService;
  
  @Autowired
  public FooController(FooService fooService) {
      this.fooService = fooService;
  }
  
  //使用方式上同，略
}

Spring4.x版本中推荐的注入方式，相较于field注入方式，就显得有点难看，特别是当注入的依赖很多（5个以上）的时候，就会明显的发现代码臃肿。
构造器注入的好处后面单独讨论。

3 setter注入

@Controller
public class FooController {
  
  private FooService fooService;
  
  //使用方式上同，略
  @Autowired
  public void setFooService(FooService fooService) {
      this.fooService = fooService;
  }
}

在Spring3.x刚推出的时候，推荐使用注入的就是这种，现在很少使用这种注解方式，写起来麻烦，当初推荐Spring自然也有他的道理: 构造器注入参数太多了，显得很笨重，另外setter的方式能用让类在之后重新配置或者重新注入。

构造器注入的好处

Spring在文档里怎么说：

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.

简单的翻译一下：构造器注入的方式，能够保证注入的组件不可变，并且确保需要的依赖不为空。此外，构造器注入的依赖总是能够在返回客户端（组件）代码的时候保证完全初始化的状态。

1 依赖不可变

属性使用final关键字修饰

2 依赖不为空

（省去了我们对null的检查）
当要实例化类的时候，由于类已经实现了有参数的构造函数，所以不会调用默认构造函数，那么就需要Spring容器传入所需要的参数，所以就两种情况：1、有该类型的参数->传入，OK 。2：无该类型的参数->报错。所以保证不会为空，Spring不会传一个null进去
如果使用field注入，缺点显而易见，因为你不调用将一直无法发现NPE的存在。

3 完全初始化状态

这个可以跟上面的依赖不为空结合起来，向构造器传参之前，要确保注入的内容不为空，那么肯定要调用依赖组件的构造方法完成实例化。而在Java类加载实例化的过程中，构造方法是最后一步（之前如果有父类先初始化父类，然后自己的成员变量，最后才是构造方法）。所以返回来的都是初始化之后的状态。

4 避免循环依赖

使用field注入可能会导致循环依赖，即A里面注入B，B里面又注入A：

public class A {
    @Autowired
    private B b;
}
​
public class B {
    @Autowired
    private A a;
}

使用构造器注入，在spring项目启动的时候，就会抛出：BeanCurrentlyInCreationException：Requested bean is currently in creation: Is there an unresolvable circular reference？从而提醒你避免循环依赖；
如果是field注入的话，启动的时候不会报错，在使用那个bean的时候才会报错。

5 总结

1. 保证依赖不可变（final关键字）
2. 保证依赖不为空（省去了我们对其检查）
3. 避免了循环依赖
4. 当有一个依赖有多个实现的使用，推荐使用field注入或者setter注入的方式来指定注入的类型

Q1：跟3.x里说的一样，我要是有大量的依赖要注入，构造方法不会显得很臃肿吗？
对于这个问题，说明你的类当中有太多的责任，那么你要好好想一想是不是自己违反了类的单一性职责原则，从而导致有这么多的依赖要注入。
Q2：是不是其他的注入方式都不适合用了呢？
存在即是合理！setter的方式既然一开始被Spring推荐肯定是有它的道理，像之前提到的setter的方式能用让类在之后重新配置或者重新注入，就是其优点之一。除此之外，如果一个依赖有多种实现方式，我们可以使用@Qualifier，在构造方法里选择对应的名字注入，也可以使用field或者setter的方式来手动配置要注入的实现。

到此这篇关于浅谈spring DI 依赖注入方式和区别的文章就介绍到这了,更多相关spring DI 依赖注入内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论