对于一些强迫者来说,代码中有一些警告,就看起来很不爽,今天笔者我也遇到了这种问题,在SpringBoot中,使用@Autowired的时候,警告Field injection is not recommended,如下图:
Spring Team recommends : “Always use constuctor based dependency injection in your beans ,Always use assertions for mandatory dependencies”.
翻译:Spring团队建议:“总是在您的bean中使用构造函数建立依赖注入。总是使用断言强制依赖”。
这种强制依赖是不被推荐的,那么看看Spring有几种注入方式
1. 通过field注入:
@Autowired
private DependencyA dependencyA;
@Autowired
private DependencyB dependencyB;
2. 通过set方法注入:
//通过set方法注入
private DependencyA dependencyA;
private DependencyB dependencyB;
@Autowired
public void setDependencyA(DependencyA dependencyA){
this.dependencyA = dependencyA;
}
@Autowired
public void setDependencyB(DependencyB dependencyB){
this.dependencyB = dependencyB;
}
3. 通过构造器注入:
@Controller
public class Controller{
//通过构造器注入
private final DependencyA dependencyA;
private final DependencyB dependencyB;
@Autowired
public Controller(DependencyA dependencyA,DependencyB dependencyB){
this.dependencyA = dependencyA;
this.dependencyB = dependencyB;
}
}
当你使用构造器方式注入,构造器参数的数量就会变得太多以至于很容易出现错误。拥有太多的依赖通常意味着你的类要承担更多的责任,明显违背了单一职责原则和关注点分离,这是一个很好的现象,表明该类需要进一步检查和重构。在直接注入filed时,没有这样的危险信号,因为这种方法可以无限扩展。
相比较而言:
field的注入方式:
优点:
变量方式注入非常简洁,没有任何多余代码,非常有效的提高了java的简洁性。即使再多几个依赖一样能解决掉这个问题。
缺点:
不能有效的指明依赖。相信很多人都遇见过一个bug,依赖注入的对象为null,在启动依赖容器时遇到这个问题都是配置的依赖注入少了一个注解什么的,然而这种方式就过于依赖注入容器了,当没有启动整个依赖容器时,这个类就不能运转,在反射时无法提供这个类需要的依赖。
set的注入方式:
在使用set方式时,这是一种选择注入,可有可无,即使没有注入这个依赖,那么也不会影响整个类的运行。
构造器的注入方式:
在使用构造器方式时已经显式注明必须强制注入。通过强制指明依赖注入来保证这个类的运行。
另一个方面:
依赖注入的核心思想之一就是被容器管理的类不应该依赖被容器管理的依赖,换成白话来说就是如果这个类使用了依赖注入的类,那么这个类摆脱了这几个依赖必须也能正常运行。然而使用变量注入的方式是不能保证这点的。
既然使用了依赖注入方式,那么就表明这个类不再对这些依赖负责,这些都由容器管理,那么如何清楚的知道这个类需要哪些依赖呢?它就要使用set方法方式注入或者构造器注入。
总结:
field方式注入应该尽量避免,使用set方式注入或者构造器注入,这两种方式的选择就要看这个类是强制依赖的话就用构造器方式,选择依赖的话就用set方法注入。
使用set方式注入:(在没有强制依赖的推荐,比如注入service,注入dao,这样可以执行set方法,set方法里能加入判空代码,直接的看出依赖有木有注入成功)
@RestController
public class UserController {
private UserService userService;
@Autowired
public void setUserService(UserService userService) {
this.userService = userService;
}
@RequestMapping("/getUserById/{id}")
public User getUserById(@PathVariable("id") Long id){
return userService.getUserById(id);
}
}