Spring 框架中依赖注入注解 @Autowired 的使用问题记录
问题描述
在使用 Spring 框架的依赖注入注解 @Autowired 时，IntelliJ IDEA 报出了一个警告：
@Autowired
UserDao userDao;
警告内容为：
Field injection is not recommended
意思是变量（Field）注入的方式不被推荐。
问题分析
IDEA 的警告提示了一种更优的实践方式：
Always use constructor-based dependency injection in your beans. Always use assertions for mandatory dependencies.
即推荐使用构造器注入的方式来强制注入依赖。
依赖注入（Dependency Injection, DI）在 Spring 中有三种实现方式：
- 变量（Field）注入
- 构造器注入
- Setter 方法注入
以下是三种方式的实现代码示例：
1. 变量（Field）注入
@Autowired
UserDao userDao;
2. 构造器注入
private final UserDao userDao;
@Autowired
public UserServiceImpl(UserDao userDao) {
this.userDao = userDao;
}
3. Setter 方法注入
private UserDao userDao;
@Autowired
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
三种注入方式的比较
1. 变量（Field）注入
- 优点：代码简洁，无需额外的构造器或 Setter 方法，适合依赖较多的情况。
- 缺点：
- 无法明确指明依赖关系，容易导致依赖注入失败（如注入对象为
null）。 - 过度依赖 Spring 容器，脱离容器后无法正常运行。
- 不符合依赖注入的核心思想，即被容器管理的类不应依赖容器的具体实现。
- 无法明确指明依赖关系，容易导致依赖注入失败（如注入对象为
2. 构造器注入
- 优点：
- 强制指明依赖关系，确保依赖在对象创建时就被注入。
- 更适合强制依赖的场景，能够保证类的完整性和不可变性（通过
final关键字）。 - 更容易进行单元测试，因为依赖可以通过构造器直接传入。
- 缺点：依赖较多时，构造器参数列表会较长。
3. Setter 方法注入
- 优点：
- 适合可选依赖的场景，依赖可以有选择性地注入。
- 灵活性较高，适合依赖可能动态变化的场景。
- 缺点：
- 无法保证依赖的强制性，可能导致依赖未注入时出现运行时错误。
- 代码量较多，每个依赖都需要一个 Setter 方法。
依赖注入的核心思想
依赖注入的核心思想之一是：被容器管理的类不应该依赖容器的具体实现。换句话说，即使脱离依赖注入容器，类也应该能够正常运行。变量注入的方式无法满足这一点，因为它强依赖于容器来提供依赖。
通过构造器注入或 Setter 方法注入，可以更清晰地表达类的依赖关系：
- 构造器注入：适用于强制依赖，确保依赖在对象创建时就被注入。
- Setter 方法注入：适用于可选依赖，提供更大的灵活性。
总结与最佳实践
- 避免使用变量注入：虽然变量注入代码简洁，但其缺点明显，容易导致依赖注入失败，且不符合依赖注入的核心思想。
- 推荐使用构造器注入：对于强制依赖，优先使用构造器注入，能够确保依赖的完整性和不可变性。
- 可选使用 Setter 方法注入：对于可选依赖，可以使用 Setter 方法注入，提供更大的灵活性。
最佳实践示例：
@Service
public class UserServiceImpl implements UserService {
private final UserDao userDao;
@Autowired
public UserServiceImpl(UserDao userDao) {
this.userDao = userDao;
}
// 业务方法
public void doSomething() {
userDao.someMethod();
}
}
通过遵循上述最佳实践，可以编写出更健壮、更易维护的 Spring 应用程序。
