面试官:为什么 Spring 和 IDEA 都不推荐使用 @Autowired 注解??

共 2526字,需浏览 6分钟

 ·

2022-09-20 22:06

点击关注公众号,Java干货 及时送达 e6b36306413f13b58df03adad58e87f0.webp

作者:小亮哥Ya
链接:https://juejin.cn/post/7080441168462348319

大家在使用IDEA开发的时候有没有注意到过一个提示,在字段上使用Spring的依赖注入注解@Autowired后会出现如下警告:

Field injection is not recommended (字段注入是不被推荐的)

但是使用@Resource却不会出现此提示

网上文章大部分都是介绍两者的区别,没有提到为什么,当时想了好久想出了可能的原因,今天来总结一下。另外,最新 Spring 面试题整理好了,大家可以在Java面试库小程序在线刷题。

Spring常见的DI方式

  • 构造器注入:利用构造方法的参数注入依赖
  • Setter注入:调用Setter的方法注入依赖
  • 字段注入:在字段上使用@Autowired/Resource注解

推荐一个开源免费的 Spring Boot 最全教程:

https://github.com/javastacks/spring-boot-best-practice

@Autowired VS @Resource

事实上,他们的基本功能都是通过注解实现依赖注入,只不过@AutowiredSpring定义的,而@ResourceJSR-250定义的。

  • 依赖识别方式:@Autowired默认是byType可以使用@Qualifier指定Name,@Resource默认ByName如果找不到则ByType
  • 适用对象:@Autowired可以对构造器、方法、参数、字段使用,@Resource只能对方法、字段使用
  • 提供方:@Autowired是Spring提供的,@Resource是JSR-250提供的

各种DI方式的优缺点

参考Spring官方文档,建议了如下的使用场景:

  • 构造器注入强依赖性(即必须使用此依赖),不变性(各依赖不会经常变动)
  • Setter注入可选(没有此依赖也可以工作),可变(依赖会经常变动)
  • Field注入:大多数情况下尽量少使用字段注入,一定要使用的话, @Resource相对@Autowired对IoC容器的耦合更低

Field注入的缺点

  • 不能像构造器那样注入不可变的对象
  • 依赖对外部不可见,外界可以看到构造器和setter,但无法看到私有字段,自然无法了解所需依赖
  • 会导致组件与IoC容器紧耦合(这是最重要的原因,离开了IoC容器去使用组件,在注入依赖时就会十分困难)
  • 导致单元测试也必须使用IoC容器,原因同上
  • 依赖过多时不够明显,比如我需要10个依赖,用构造器注入就会显得庞大,这时候应该考虑一下此组件是不是违反了单一职责原则

为什么IDEA只对@Autowired警告

Field注入虽然有很多缺点,但它的好处也不可忽略:那就是太方便了。使用构造器或者setter注入需要写更多业务无关的代码,十分麻烦,而字段注入大幅简化了它们。并且绝大多数情况下业务代码和框架就是强绑定的,完全松耦合只是一件理想上的事,牺牲了敏捷度去过度追求松耦合反而得不偿失。

那么问题来了,为什么IDEA只对@Autowired警告,却对@Resource视而不见呢?另外,最新 Spring 面试题整理好了,大家可以在Java面试库小程序在线刷题。

个人认为,就像我们前面提到过的:@AutowiredSpring提供的,它是特定IoC提供的特定注解,这就导致了应用与框架的强绑定,一旦换用了其他的IoC框架,是不能够支持注入的。

@ResourceJSR-250提供的,它是Java标准,我们使用的IoC容器应当去兼容它,这样即使更换容器,也可以正常工作。

End


Spring Boot 学习笔记,这个太全了!

23 种设计模式实战(很全)

Nacos 2.1.1 正式发布,真心强!

Spring Cloud Alibaba 最新重磅发布!

面试通过,背调凉了。。

f72f354fdd62b58012a1ce42d90587ce.webpSpring Cloud 微服务最新课程!
浏览 40
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报