背景
- 我们在使用Spring写web项目的时候,非常喜欢使用@Resource,@Autoweired注解。
- 我们也可以使用构造器的方式进行依赖注入。
- 也可以使用set方法进行依赖注入。
- 可是,我们有思考过究竟用哪种方式更好啊?Spring官方推荐使用构造器的方式进行依赖注入
过程
-
spring的依赖注入,一般我们使用注解@Resource, @Autowired , 但是也依然可以使用构造器的方式进行依赖注入,或者set方法依赖注入。
@Autowired 加上构造器方法,方法体中的内容就是给属性进行赋值。 @Autowired 加上setXxx方法,方法体中的内容就是给属性赋值。 -
有这么多依赖注入方式,那我们应该选择哪个?
-
@Autowired @Resource 简单,简洁
-
构造器在属性特别多的是,就显得很是臃肿,代码不美观。
-
set方法比较纯粹,但是没有@Autowire @Resource 简洁。
-
如果我们在使用@Autowired 和 @Resource 这样的注解的时候,其实很容易在代码中写出了循环依赖的问题。 虽然spring框架本身解决了循环依赖的问题,启动项目不报错,但是如果某个方法调用了循环依赖对象的方法,方法中出现循环依赖,那么就是一个死循环方法执行?
-
要这样思考:spring解决循环依赖,只是没有让项目报错,只是让对象之间在循环依赖的场景中生存。因此,我们的目的是:尽可能避免循环依赖这样的事情。
-
构造器依赖注入:就能够提前暴露项目中的代码出现了循环依赖,我们应该去解决这个循环依赖的现象。
-
如果考虑到构造器进行依赖注入的属性过多,而显得很臃肿的情况。
①我们应该去思考的问题是:类的职责是否单一。
②也就是: 我的一个类最多依赖注入:几个属性。
③但是,实际开发过程中, 由于业务复杂度的增加,往往导致一个类属性特别多。
- spring依赖注入的结论
-
采用spring推荐做法,构造器依赖注入。
-
考虑到代码臃肿,不美观的情况。我们采用lombok的注解即可,完美。
-
理解到为什么自己要使用构造器进行依赖注入。提前避免出现循环依赖情况。
小结
-
构造器进行依赖注入。
-
提供了一个思路?
- 我要用构造器进行依赖注入,然而它既带来的优点,也带来了缺点。
- 然而,缺点,虽然没有本质解决它,但是采用了lombok这样的简化手段。因为lombok简化了代码,美化了编辑界面。
- 其他关于Spring的依赖注入的细节问题
- 细节,有的时候,代码提示不能够自动注入。是因为这个接口可能有多个实现。
- 采用@Qualifier的方式指定要哪个具体的对象。
- 虽然接口有很多实现,但是采用了Conditional这样的注解,一般情况下,应用程序中也只有一个有效的实例对象。因此,使用自动注入也依然是合理的。