【JavaEE】Spring的开发要点总结（3）
文章目录
- 【JavaEE】Spring的开发要点总结（3）
- [1. 属性注入](#1. 属性注入)
- [1.1 @Autowired注解](#1.1 @Autowired注解)
- [1.2 依赖查找 VS 依赖注入](#1.2 依赖查找 VS 依赖注入)
- [1.3 配合@Qualifier 筛选Bean对象](#1.3 配合@Qualifier 筛选Bean对象)
- [1.4 属性注入的优缺点](#1.4 属性注入的优缺点)
- [2. Setter注入](#2. Setter注入)
- [2.1 @Autowired注解](#2.1 @Autowired注解)
- [2.2 命名规则](#2.2 命名规则)
- [2.3 Setter注入的优缺点](#2.3 Setter注入的优缺点)
- [3. 构造方法注入](#3. 构造方法注入)
- [3.1 @Autowired注解](#3.1 @Autowired注解)
- [3.2 命名规则](#3.2 命名规则)
- [3.3 构造方法注入的优缺点](#3.3 构造方法注入的优缺点)
- [4. 另一个注入可以用的注解@Resource](#4. 另一个注入可以用的注解@Resource)
- [4.1 来源不同](#4.1 来源不同)
- [4.2 匹配机制不同](#4.2 匹配机制不同)
- [4.3 参数不同](#4.3 参数不同)
- [4.4 @Resource多一个匹配Bean对象名称的方案](#4.4 @Resource多一个匹配Bean对象名称的方案)
- [4.5 使用上的区别](#4.5 使用上的区别)
- [5. 综合练习](#5. 综合练习)
【JavaEE】Spring的开发要点总结（3）
在前面的代码里，我们获取Bean对象也比较麻烦：
本文章就是为了更方便地去获取Bean对象~
- 对象装配
- 也叫 对象注入
那么有没有对应的注解去实现这个功能呢？
Spring提供的三种实现方法：
- 属性注入
- 构造方法注入
- Setter注入
而这种非明文获取Bean对象的过程，就是DI
- 而之前就是DL
首先，先创建一个新的项目，这次用规范的写法（工程分层）：
- 配置文件自己去配~
在对应的层就是对应的注解：
1. 属性注入
这是数据持久层的一个插入方法，而 这个方法理论上是要在service层去调用的
但是new对象的写法在Spring已经不用啦：
属性注入则可以更便捷获取Bean对象~
1.1 @Autowired注解
自动接通吧，差不多那个意思~
利用这个注解，就能有以下操作：
这就是依赖注入，DI~
不用通过代码显示查找
- 而是在Spring中，隐式用高效的方式自动地扫描到对应的Bean对象（n. 依赖）
- 然后赋值（v. 注入）给这个成员属性
测试一下：
- new对象的方式不行，跟Bean对象是否加载存储到Spring中五无关~
也可以通过单元测试的方式去测试代码，后期更新测试开发博客文章的时候讲解~
1.2 依赖查找 VS 依赖注入
参考之前的文章：
在这里体现出来的一点就是，依赖查找依赖Bean的名称，而依赖注入则会自动匹配和找到Bean对象，注入到属性中
- 不是说依赖注入没有"查找"的过程，只是依赖注入重点在于注入
DI 流程是这样的：
- getType，从容器中获取对象
- 如果能拿到唯一一个，那么就直接赋值给属性变量里
- 这个时候变量名没有要求~
- 正如上面写的~
- 如果找到多个，则根据名称去匹配对应的Bean对象！
测试结果：
- 确实是不同的Bean对象~
- 也验证了 DI 使用名称去匹配~
- 这个时候你的变量名就必须是Bean对象其中一个的名称了~
- 否则会报找不到，不唯一...的异常
1.3 配合@Qualifier 筛选Bean对象
你不管三七二十一，就想要一个响当当的属性名："userSuperDao"，但是没有这个名的Bean对象（现在有多个Bean）
你就可以利用这个注解：
1.4 属性注入的优缺点
参考链接： https://juejin.cn/post/7135235294265081887
优点：实现/使用简单
缺点：
- 无法注入到一个不可变的变量（final 修饰的变量）
原因是final的特征：
- 被final修饰的成员变量要在
- 定义时直接被赋值
- 构造方法中第一次赋值
- 实例代码块中第一次赋值
- 除了成员变量外的final变量，要在第一次赋值后不能被修改
- 通用性问题
- 测试困难
- 依赖项之间的耦合
- 运行时的验证困难
- 依赖关系的不清楚，复杂
- 我们这种简单地用，@Autowired注解在属性上，去注入的方式可能不适用与非IoC容器的
- 而Setter和构造方法注入是通过调用方法的，所以没有这个问题
- 设计原则问题：更容易违背单一设计原则
参考官方文档：Spring | Home
单一设计原则要求一个类应该只有一个引起改变的原因，即一个类应该只有一个主要责任。当使用属性注入时，可能会出现以下情况：
- 因为开销比较小，在这个类里有啥需要就写一个属性，涉及多个职责耦合
- 依赖关系不清楚，乱，说到底还是属性写太多，设计不单一
但是，开发就是这样，不会很完美，3这个点很难避开
- 有时候为了速度，牺牲耦合性的情况也有
- 比如一个页面的信息有分类的，有不同的职责
- 但是，如果访问这个页面，要去访问那么多个接口，就有很多次"三次握手四次挥手"了
- 实际场景实际分析！
2. Setter注入
顾名思义，借此模仿，就是Setter方法加对应的注解
2.1 @Autowired注解
这就自动在Spring中找到Bean对象，然后通过Setter注入给对应的成员变量~
- DI，是这样的
测试：
2.2 命名规则
命名规则跟属性注入基本一致，你可以理解为属性注入套了层皮，就是Setter注入
正好现在我有两个UserDao的Bean对象，来演示一下：
- 一个aaa，一个userDao
观察一下，再看答案：
- 跟方法名无关
- 跟属性名无关
- 跟方法的参数名有关
- 可以结合@Qualifier注解
规则：
- 通过参数的类型，如果只获得一个Bean对象，那么这个属性的名字是啥都OK
- 如果获取到多个Bean对象，则需要 通过属性名进行匹配
- @Qualifier去筛选，就不用考虑参数名的问题~
2.3 Setter注入的优缺点
优点：
- 通常情况下，构造Setter只去Set一两个属性，并不会构造全部的Setter方法
所以Setter注入，更符合单一设计原则，就不会像属性注入那样的广泛
通用性更好一点（相对于属性注入）
- 属性注入如果在别的容器上，失效了，但是Setter注入暴露出一个Set方法了呀，我们可以通过Set方法去挽救，自己手动赋值个Bean对象/new一个进去~
- 而属性注入的属性，一般是private，在别的类不能直接修改其值
这个优点很牵强 ^ _ ^
缺点：
- 无法注入到一个final修饰的变量
- Setter注入的对象可以被修改
- 相比于属性注入，Setter方法是公开的，所以这个方法可能被多次调用并修改
- 这样就导致注入的结果被覆盖~
- 或者原本设置的值被注入修改~
- 属性注入也可以，但是是private，所以只能在对应的类中修改
3. 构造方法注入
这是官方推荐的一种注入方式~
- 虽然如此，官方写的代码，用这个的不多🤣
- 虽然更加完美，但是写起来麻烦
(Spring 4.x 之后推荐的注入方式)
3.1 @Autowired注解
- 在构造方法上加上个@Autowired注解~
这也是标准的写法~
不标准的写法，不加@Autowired注解不会报错：
- 因为官方推荐，所以搞了点小特殊🤣
- 这个类如果只有一个构造方法的情况下，才是可以省略的！
- 空的构造方法还行，就相当于啥也不注入，至少在构造UserService3的时候可以调用这个方法
- 这个方法直接是不能调用了，因为不确定调用哪个构造方法，该注入啥
加上就不会有事：
原理就是：
- 框架在构造UserService的时候，会根据@Autowried去挑选构造方法，而参数的来源就是Bean对象
- 因此构造方法就会将这些Bean对象注入到属性上
所以不能有多个@Autowired修饰的构造方法：
3.2 命名规则
跟Setter注入一样！
- 只不过不能用@Qualifier注解！
- 这个类只有一个Bean对象，那么参数名无所谓
- 这个类有多个Bean对象，那么参数名必须要匹配对应的Bean对象的名称
3.3 构造方法注入的优缺点
优点：
- 可以注入到一个final修饰的变量
- 因为构造方法的第一次赋值final变量是允许的
- 但是一定要保证每个构造方法涉及到的成员，都包含所有的final变量，即保证final变量都可以被初始化
- 一个都不能缺
运行结果没问题：
注入的对象不会被修改，因为构造方法只会加载一次
- 硬要修改还是可以的，只不过不能通过构造方法
保证使用的时候，注入对象都被初始化了
通用性更好（相对其他）
- 同Setter注入
- 因为必须传值，因为优点3
缺点：
- 可以传入多个属性，不太符合单一设计原则
- 这一点是写代码方面的初心问题吧。因为硬要这么说，你完全也可以给那个别的属性构造个Setter呀
- 写法比较复杂
- 无法解决循环依赖的问题
- a依赖b，b依赖a，就是一个"循环"
- 得用Spring三级缓存去解决
- 这个循环依赖后面详细讲，现在就了解一下~
常见的面试题就是三者的区别：就是把他们的使用和优缺点讲一下~
4. 另一个注入可以用的注解@Resource
这个可以直接替换@Autowired注解，用IDEA专业版的话，有些场景下，用@Autowired是会报错的~
- 但是属于误报，运行还是可以运行（设置把报错信息忽略掉）~
Resource就没啥问题：
用法基本一致：
这也是个常见的面试题：@Autowired和@Resource的区别是什么？
4.1 来源不同
@Autowired来自Spring框架，而@Resource来自JavaEE规范
4.2 匹配机制不同
- @Autowired先进行类型匹配再用名称匹配
- 但是专业版在这个注解判断代码正确与否的时候，并不会进一步用名称去匹配
- 所以会误报
- @Resource先进行名称匹配再进一步用类型匹配
- 名称对不上，也会用类型去找，有多个Bean会报错，只有一个Bean就忽略名称的问题
- 当然误报的原因可能有很多，甚至不是单一的原因...
- IDEA兼容性不同~
4.3 参数不同
@Autowired只有一个参数，required，而@Resource没有这个参数，但是有很多其他的参数
required默认为true，代表要求Bean注入一定要存在
required设置为false，代表不要求Bean一定存在，不注入即可，就不会报找不到Bean对象异常~
4.4 @Resource多一个匹配Bean对象名称的方案
因此，@Resource多了一个匹配名称的方案：设置name的值即可：
4.5 使用上的区别
@Resource不支持构造方法注入
5. 综合练习
补充： 无论怎么样，静态属性是无法被注入Bean的，因为静态属性的加载是在Spring之前的，即类加载的时候，是这个类通用的属性，而Bean对象是一个实例！难不成每次获取Bean对象，Spring都会注入覆盖这个值吗~
这不合理~
- 而依赖注入发生在你获取Bean对象的时候，Spring帮你构造实例的时候，而不是你自己new和设置的时候
- 所以在main方法中，还是要通过DL去获取Bean
要求：在Spring项目中，通过main方法获取到Controller类，在Controller类里调用Service类，在Service类中获取Dao类，在Dao类中的一个方法，用伪代码new一个User，进行返回，返回给main方法，打印user。
报错了，这也是常见的问题，就Test类并没有在demo目录下，而是与其并列，要把他放进目录里：
运行结果：
是不是跟之前普通java代码对IoC的理解思想差不多😀
文章到此结束！谢谢观看
可以叫我 小马 ，我可能写的不好或者有错误，但是一起加油鸭🦆！
代码链接：
- SpringDemo3 · 游离态/马拉圈2023年7月 - 码云 - 开源中国 (gitee.com)
- SpringDemo4 · 游离态/马拉圈2023年7月 - 码云 - 开源中国 (gitee.com)
用注解的方式去获取Bean对象，是不是很方便🤭