国家建设标准网站,延边州网站建设,wordpress提问插件,wordpress网站换空间【JavaEE】Spring的开发要点总结#xff08;3#xff09; 文章目录 【JavaEE】Spring的开发要点总结#xff08;3#xff09;1. 属性注入1.1 Autowired注解1.2 依赖查找 VS 依赖注入1.3 配合Qualifier 筛选Bean对象1.4 属性注入的优缺点 2. Setter注入2.1 Autowired注解2.2… 【JavaEE】Spring的开发要点总结3 文章目录 【JavaEE】Spring的开发要点总结31. 属性注入1.1 Autowired注解1.2 依赖查找 VS 依赖注入1.3 配合Qualifier 筛选Bean对象1.4 属性注入的优缺点 2. Setter注入2.1 Autowired注解2.2 命名规则2.3 Setter注入的优缺点 3. 构造方法注入3.1 Autowired注解3.2 命名规则3.3 构造方法注入的优缺点 4. 另一个注入可以用的注解Resource4.1 来源不同4.2 匹配机制不同4.3 参数不同4.4 Resource多一个匹配Bean对象名称的方案4.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依赖bb依赖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的理解思想差不多 【JavaEE】JavaEE进阶框架的学习 - Spring的初步认识_s:103的博客-CSDN博客 文章到此结束谢谢观看 可以叫我 小马我可能写的不好或者有错误但是一起加油鸭 代码链接 SpringDemo3 · 游离态/马拉圈2023年7月 - 码云 - 开源中国 (gitee.com)SpringDemo4 · 游离态/马拉圈2023年7月 - 码云 - 开源中国 (gitee.com) 用注解的方式去获取Bean对象是不是很方便
