记录一下spring注入的东西
# 介绍
# @Autowired注入
@RestController
@RequestMapping("/test")
public class TestController {
@Autowired
private TestService testService;
@Autowired
private TestService1 testService1;
private Testtarget target;
}
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
# 构造器注入
Spring4.3+之后，constructor注入支持非显示注入方式。
@RestController
@RequestMapping("/test")
public class TestController {
// @Autowired
private final TestService testService;
// @Autowired
private final TestService1 testService1;
// @Autowired
public TestController(TestService testService, TestService1 testService1) {
this.testService = testService;
this.testService1 = testService1;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
# setter注入
@RestController
@RequestMapping("/test")
public class TestController {
// @Autowired
private final TestService testService;
// @Autowired
private final TestService1 testService1;
@Autowired
public void setTestService(TestService testService){
this.testService = testService;
}
@Autowired
public void setTestService1(TestService1 testService1){
this.testService1 = testService1;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Mark
事实上，spring在4.x版本后就推荐使用构造器的方式的来注入fileld
官方推荐理由:
单一职责:
当使用构造函数注入的时候，你会很容易发现参数是否过多，这个时候需要考虑你这个类的职责是否过大，考虑拆分的问题；而当使用@Autowired注入field的时候，不容易发现问题
依赖不可变:
只有使用构造函数注入才能注入final
依赖隐藏:
使用依赖注入容器意味着类不再对依赖对象负责，获取依赖对象的职责就从类抽离出来，IOC容器会帮你自动装备。这意味着它应该使用更明确清晰的公用接口方法或者构造器，这种方式就能很清晰的知道类需要什么和到底是使用setter还是构造器
降低容器耦合度:
依赖注入框架的核心思想之一是托管类不应依赖于所使用的DI容器。换句话说，它应该只是一个普通的POJO，只要您将其传递给所有必需的依赖项，就可以独立地实例化。这样，您可以在单元测试中实例化它，而无需启动IOC容器并单独进行测试（使用一个可以进行集成测试的容器）。如果没有容器耦合，则可以将该类用作托管或非托管类，甚至可以切换到新的DI框架。
另外，在使用构造器的使用能避免注入的依赖是空的情况。
因为在bean的生命周期里面先执行的是bean的构造器，然后才给bean里面的属性赋值。