idea中@Autowired注解下变量报红的解决
idea中@Autowired注解下变量报红
问题
idea中@Autowired注解下变量报红
这个不是错误,只是一个警告而已,其实不解决也是可以启动项目的
解决方法
1、修改设置
file–>settings–>Inspections–>spring Core–>Code–>Autowiring for Bean Class
2、修改注解@Autowired为注解@Resource
3、注解@Autowired的属性required = false
4、对应的dao层代码添加注解@Repository(“UserDao”)
注解@Autowired--警告(亲测可用)
@Autowired UserDao userDao;
警告内容是
Field injection is not recommended
意思就是使用变量依赖注入的方式是不被推荐的。
使用idea解决策略是这样的:
Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies
意思就是总是使用构造器的方式强制注入。
依赖注入有三种方式:
- 变量(filed)注入
- 构造器注入
- set方法注入
先各自看一下实现方式
变量(filed)注入
@Autowired UserDao userDao;
构造器注入
final UserDao userDao; @Autowired public UserServiceImpl(UserDao userDao) { this.userDao = userDao; }
set方法注入
private UserDao userDao; @Autowired public void setUserDao (UserDao userDao) { this.userDao = userDao; }
(我遇到该错误使用了第三种方法)
相比较而言:
优点:变量方式注入非常简洁,没有任何多余代码,非常有效的提高了java的简洁性。即使再多几个依赖一样能解决掉这个问题。
缺点:不能有效的指明依赖。相信很多人都遇见过一个bug,依赖注入的对象为null,在启动依赖容器时遇到这个问题都是配置的依赖注入少了一个注解什么的,然而这种方式就过于依赖注入容器了,当没有启动整个依赖容器时,这个类就不能运转,在反射时无法提供这个类需要的依赖。
在使用set方式时,这是一种选择注入,可有可无,即使没有注入这个依赖,那么也不会影响整个类的运行。
在使用构造器方式时已经显式注明必须强制注入。通过强制指明依赖注入来保证这个类的运行。
另一个方面:
依赖注入的核心思想之一就是被容器管理的类不应该依赖被容器管理的依赖,换成白话来说就是如果这个类使用了依赖注入的类,那么这个类摆脱了这几个依赖必须也能正常运行。然而使用变量注入的方式是不能保证这点的。
既然使用了依赖注入方式,那么就表明这个类不再对这些依赖负责,这些都由容器管理,那么如何清楚的知道这个类需要哪些依赖呢?它就要使用set方法方式注入或者构造器注入。
小结下
变量方式注入应该尽量避免,使用set方式注入或者构造器注入,这两种方式的选择就要看这个类是强制依赖的话就用构造器方式,选择依赖的话就用set方法注入。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家.
相关文章
SpringBoot中使用spring-retry 解决失败重试调用
本文主要介绍了SpringBoot中使用spring-retry 解决失败重试调用,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-07-07Graceful Response 构建 Spring Boot 响应
Graceful Response是一个Spring Boot技术栈下的优雅响应处理器,提供一站式统一返回值封装、全局异常处理、自定义异常错误码等功能,本文介绍Graceful Response 构建 Spring Boot 下优雅的响应处理,感兴趣的朋友一起看看吧2024-01-01
最新评论