CTO 说了,用错@Autowired 和@Resource 的人可以领盒饭了

提示的警告信息

Field injection is not recommended Inspection info: Spring Team recommends: “Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies”.

这段是Spring工作组的建议,大致翻译一下:

属性字段注入的方式不推荐,检查到的问题是:Spring团队建议:“始终在bean中使用基于构造函数的依赖项注入,始终对强制性依赖项使用断言”

如图

CTO 说了,用错@Autowired 和@Resource 的人可以领盒饭了

Field注入警告

注入方式

====

虽然当前有关Spring Framework(5.0.3)的文档仅定义了两种主要的注入类型,但实际上有三种:

基于构造函数的依赖注入

public class UserServiceImpl implents UserService{

private UserDao userDao;

@Autowire

public UserServiceImpl(UserDao userDao){

this.userDao = userDao;

}

}

基于Setter的依赖注入

public class UserServiceImpl implents UserService{

private UserDao userDao;

@Autowire

public serUserDao(UserDao userDao){

this.userDao = userDao;

}

}

基于字段的依赖注入

public class UserServiceImpl implents UserService{

@Autowire

private UserDao userDao;

}

基于字段的依赖注入方式会在Idea当中吃到黄牌警告,但是这种使用方式使用的也最广泛,因为简洁方便.您甚至可以在一些Spring指南中看到这种注入方法,尽管在文档中不建议这样做.(有点执法犯法的感觉)

如图

CTO 说了,用错@Autowired 和@Resource 的人可以领盒饭了

Spring自己的文档

基于字段的依赖注入缺点

===========

对于有final修饰的变量不好使

Spring的IOC对待属性的注入使用的是set形式,但是final类型的变量在调用class的构造函数的这个过程当中就得初始化完成,这个是基于字段的依赖注入做不到的地方.只能使用基于构造函数的依赖注入的方式

掩盖单一职责的设计思想

我们都知道在OOP的设计当中有一个单一职责思想,如果你采用的是基于构造函数的依赖注入的方式来使用Spring的IOC的时候,当你注入的太多的时候,这个构造方法的参数就会很庞大,类似于下面.

当你看到这个类的构造方法那么多参数的时候,你自然而然地会想一下:这个类是不是违反了单一职责思想?.但是使用基于字段的依赖注入不会让你察觉,你会很沉浸在@Autowire当中

public class VerifyServiceImpl implents VerifyService{

private AccountService accountService;

private UserService userService;

private IDService idService;

private RoleService roleService;

private PermissionService permissionService;

private EnterpriseService enterpriseService;

private EmployeeService employService;

private TaskService taskService;

private RedisService redisService;

private MQService mqService;

public SystemLogDto(AccountService accountService,

UserService userService,

IDService idService,

RoleService roleService,

PermissionService permissionService,

EnterpriseService enterpriseService,

EmployeeService employService,

TaskService taskService,

RedisService redisService,

MQService mqService) {

this.accountService = accountService;

this.userService = userService;

this.idService = idService;

this.roleService = roleService;

this.permissionService = permissionService;

this.enterpriseService = enterpriseService;

this.employService = employService;

this.taskService = taskService;

this.redisService = redisService;

this.mqService = mqService;

}

}

### Spring 中 `@Autowired` 与 `@Resource` 的区别及其使用场景 #### 主要区别 1. **来源不同** - `@Autowired` 是由 Spring 提供的注解,主要用于 Spring 容器中的依赖注入[^1]。 - `@Resource` 则是由 JDK 提供的标准注解,遵循 JSR-250 规范,适用于任何支持该规范的 Java 容器[^4]。 2. **默认注入方式** - `@Autowired` 默认按照类型 (`ByType`) 进行匹配并完成 Bean 的注入。如果存在多个相同类型的 Bean,则会抛出异常。 - `@Resource` 默认按照名称 (`ByName`) 进行匹配。如果没有找到对应的名称,则退而求其次按类型进行匹配。 3. **解决多实现类的情况** - 当一个接口有多个实现类时: - 对于 `@Autowired`,可以配合 `@Qualifier` 明确指定需要注入的具体 Bean 名称。 - 而对于 `@Resource`,可以直接通过其属性 `name` 来显式指定目标 Bean 的名称。 4. **灵活性与控制力** - 在 Spring 应用开发中,推荐优先使用 `@Autowired`,因为它更加贴合 Spring 的设计理念,并提供诸如懒加载(`lazy-init=true`)以及更精细的错误处理机制等功能[^2]。 #### 使用场景分析 - 如果项目完全基于 Spring 或者主要采用 Spring 技术栈构建,则应首选 `@Autowired` 实现依赖注入操作。 - 若处于混合技术环境或者希望保持代码独立性(不绑定特定框架),那么可以选择更为通用的 `@Resource` 注解。 ```java // 示例:使用 @Autowired 配合 @Qualifier 处理多实现情况 @Component public class ExampleService { @Autowired @Qualifier("specificImplementation") private MyInterface myInstance; } // 示例:使用 @Resource 指定具体 bean name @Component public class AnotherExampleService { @Resource(name="anotherSpecificImplementation") private MyInterface anotherMyInstance; } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值