深圳做地铁的公司网站,企业公示信息系统官网,英文seo如何优化,html5网页设计案例在使用IDEA进行开发时#xff0c;在字段上使用Spring的依赖注入注解Autowired后会出现如下警告 Field injection is not recommended (字段注入是不被推荐的) 这个原因具体可以看看#xff1a;
【注解使用】使用Autowired后提示#xff1a;Field injection is not recomme…在使用IDEA进行开发时在字段上使用Spring的依赖注入注解Autowired后会出现如下警告 Field injection is not recommended (字段注入是不被推荐的) 这个原因具体可以看看
【注解使用】使用Autowired后提示Field injection is not recommendedSpring团队不推荐使用Field注入 【Spring】浅谈spring为什么推荐使用构造器注入
我们这里讨论
使用Resource却不会出现此提示
网上文章大部分都是介绍两者的区别没有提到为什么 Spring常见的DI方式 构造器注入 利用构造方法的参数注入依赖 Setter注入 调用Setter的方法注入依赖 字段注入 在字段上使用Autowired/Resource注解 Resource注解也可以完成属性注入。那它和Autowired注解有什么区别 Resource注解是JDK扩展包中的也就是说属于JDK的一部分。所以该注解是标准注解更加具有通用性。(JSR-250标准中制定的注解类型。JSR是Java规范提案。) Autowired注解是Spring框架自己的。 Resource注解默认根据名称装配byName未指定name时使用属性名作为name。通过name找不到的话会自动启动通过类型byType装配。 Autowired注解默认根据类型装配byType如果想根据名称装配需要配合Qualifier注解一起用。 Resource注解用在属性上、setter方法上。 Autowired注解用在属性上、setter方法上、构造方法上、构造方法参数上。 各种DI方式的优缺点
参考Spring官方文档建议了如下的使用场景 构造器注入 强依赖性 即必须使用此依赖不变性 各依赖不会经常变动 Setter注入 可选 没有此依赖也可以工作可变 依赖会经常变动 Field注入 大多数情况下尽量少使用 字段注入一定要使用的话 Resource相对Autowired 对IoC容器的耦合更低 Field注入的缺点 不能像构造器那样注入不可变的对象 依赖对外部不可见 外界可以看到构造器和setter但无法看到私有字段自然无法了解所需依赖 会导致组件与IoC容器紧耦合 这是最重要的原因离开了IoC容器去使用组件在注入依赖时就会十分困难 导致单元测试也必须使用IoC容器 原因同上 依赖过多时不够明显 比如我需要10个依赖用构造器注入就会显得庞大这时候应该考虑一下此组件是不是违反了单一职责原则 为什么IDEA只对Autowired警告
Field注入虽然有很多缺点但它的好处也不可忽略那就是太方便了 。使用构造器或者setter注入需要写更多业务无关的代码十分麻烦而字段注入大幅简化了它们。并且绝大多数情况下业务代码和框架就是强绑定的完全松耦合只是一件理想上的事牺牲了敏捷度去过度追求松耦合反而得不偿失。
那么问题来了为什么IDEA只对Autowired警告却对Resource视而不见呢
1、Autowired 是Spring 提供的它是特定IoC提供的特定注解 这就导致了应用与框架的强绑定 一旦换用了其他的IoC框架是不能够支持注入 的。
而 Resource 是JSR-250 提供的它是Java标准 我们使用的IoC容器应当去兼容它这样即使更换容器也可以正常工作。 2、Autowired和 Resource的默认注入方式不同Autowired默认是根据类型进行注入的 Resource默认是先根据名字注入找不到再根据类型注入的。所以相比于 Autowired 注解Resource 注解更加灵活但同时也更难以确保依赖项的正确性。如果无法确定自动注入的 Bean 是否正确可以通过 Qualifier 注解或者手动注入的方式显式指定 Bean 的名称或类型避免依赖项注入的错误和困扰。
参考文章
为什么在Spring中使用Autowired时会报错 而Resource不会
为什么 Spring和IDEA 都不推荐使用 Autowired 注解