Spring
Spring
为什么要学
- 从使用和占有率看
- Spring在市场的占有率与使用率高
- Spring在企业的技术选型命中率高
- 从专业角度看
- spring可以简化开发,降低企业级开发的复杂性,是开发变得简单快捷
- spring可以框架整合,高效整合其他技术,提高企业级应用开发与运行效率
学什么
- 简化开发:spring框架中提供了两大的核心技术
- IOC
- AOP
- 事务处理(属于AOP的具体应用,可以简化项目中的事务管理)
- 框架整合:spring可以整合市面上几乎所有的主流框架,比如:
- mybaits
- mybatis-plus
- …
相关概念
spring家族
- 官网:https://spring.io, 从官网我们大概可以了解到:
- Spring可以用于开发web、微服务以及分布式系统等,光这三块就已经占了JavaEE开发的九成多
- Spring并不是单一的一个技术,而是一个大家族,可以从官网的Project中查看其包含的所有技术
- Spring发展到今天已经形成了一种开发的生态圈,Spring提供了若干个项目,每个项目用于完成特定的功能。
- 我们可以完全使用spring技术完成整个的项目的构建、设计与开发
- spring有若干个项目,可以根据需要自行选择,把这个些个项目组合起来,起了一个名称叫做全家桶。(需要重点关注Spring Framework、SpringBoot、SpringCloud)
Spring Framework
是Spring中最早最核心的技术,也是所有其他技术的基础
SpringBoot
spring是用来简化开发,而SpringBoot是来帮助Spring在简化的基础上更快速进行开发
SpringCloud
这个是用来做分布式之微服务架构的相关开发
Spring系统架构
- Spring Framework是spring生态圈最基础的项目,是其他项目的根基
- Spring Framework的发展也经历了很多的版本的变更,每个版本都有相应的调整
- 目前已4的架构做研究
- 核心层
- Core Container:核心容器,这个模块是Spring最核心的模块,其他的都需要以来该模块
- AOP层
- AOP:面向切面编程,它以来最核心层容器,目的是,在不改变原有代码的前提下对其进行功能增强
- Aspects:Aop是思想,Aspects是对AOP思想的具体实现
- 数据层
- Data Access:数据访问,Spring全家桶中有对数据访问的具体实现技术
- Data Integration:数据集成,Spring支持整合其他的数据层解决方案,比如Mybatis
- Transactions:事务,Spring中事务管理是Spring AOP的一个具体实现
- Web层
- 主要是通过SpringMvc去实现
- Test层
- Spring主要整合了Junit来完成单元测试和集成测试
从上述的系统架构来说,可以知道Spring主要包含以下四部分内容
- Spring的IOC/DI
- Sprigng的AOP
- AOP的具体应用(比如事务管理)
- IOC\DI的具体应用,整合Mybatis
Spring核心概念
目前项目中的问题
要想解答这个问题,就需要先分析下目前代码在编写过程中遇到的问题:
- 业务层需要调用数据层的方法,就需要在业务层new数据层的对象
- 如果数据层的实现类发生改变,那么业务层的代码也需要跟着改变,发生变更后,都需要进行编译打包和重部署
- 所以在这种模式的代码编写过程中存在的问题是:耦合度偏高
如果能把框中的内容给去掉,不就可以降低依赖了,但是又会引入新的问题,因为bookDao没有赋值为Null,强行运行就会出空指针异常。
现在的问题就是,业务层不想new对象,运行的时候又需要这个对象,针对这个问题,spring就提出一个解决方案:使用对象时,在主程序不要主动使用new产生对象,转换为由外部提供对象,这就是spring中的IOC思想
IOC、IOC容器、Bean、DI
IOC(控制反转)
使用对象时,由主动new产生对象转换为由外部提供对象,此过程中对象创建控制权由程序转移到外部,此思想称为控制反转
- 业务层要用数据层的类对象、以前是自己new的
- 现在自己不new的,交给外部来创建对象
- 外部就反转控制了数据层对象的创建权
- 这种思想就是控制反转
Spring和IOC的关系
- spring技术对IOC思想进行了实现
- spring提供了一个容器,称为IOC容器,用来充当IOC思想中的”外部”
- ioc思想中的外部指的就是spring的IOC容器
IOC容器作用以及内部存放
- IOC容器负责对象的创建、初始化等一系列工作,其中包含了数据层和业务层的类对象
- 被创建或被管理的对象在IOC容器中统称为Bean
- IOC容器中放的就是一个个Bean对象
IOC容器创建好了service和dao对象后,程序能正确执行吗
- 不行,因为iservice运行需要依赖dao对象
- IOC容器中虽然由service和dao对象,但是service对象和dao对象没有任何关系
- 需要把dao对象交给service,也就是说要绑定service和dao对象之间的关系,像这种在容器中建立对象与对象之间的绑定关系就要用到DI
DI(Dependency Injection)依赖注入

- 在容器中建立bean与bean之间的依赖关系的整个过程,称为依赖注入
- 业务层要用数据层的类对象,以前是自己new的
- 现在自己不new了,靠IOC容器来给注入进来,这种思想就是依赖注入
- 使用IOC容器管理bean(IOC)
- 在IOC容器内将有依赖关系的bean进行关系绑定(DI)
- 最终结果为:使用对象是不仅可以直接从IOC容器中获取,并且获取到的bean已经绑定了所有的依赖关系
小结
什么是IOC/DI思想
- IOC:控制反转的是对象的创建权
- DI:依赖注入,绑定对象与对象之间的依赖关系
什么是IOC容器
Spring创建了一个容器用来存放所创建的对象,这个容器就叫IOC容器
什么是Bean
容器中所存放的一个个对象就叫做Bean或Bean对象
IOC入门案例
思路分析
- spring是使用容器来管理bean对象的,在使用中是管什么的
- 主要管理项目中所使用到的类对象,比如service和Dao
- 如何将被管理的对象告知IOC容器
- 使用配置文件
- 被管理的对象交给IOC容器,要想从容器中获取对象,就先得思考如何获取到IOC容器
- spring框架提供相应的接口
- IOC容器得到后,如何从容器中获取Bean
- 调用spring框架提供对应接口中的方法
- 使用spring导入那些坐标
- 用别人的东西,就需要在pom.xml添加对应的依赖
代码实现
需求分析:将BookServiceImpl和BookDaoImpl交给Spring管理,并从容器中获取对应的bean对象进行方法调用。
1.创建Maven的java项目
2.pom.xml添加Spring的依赖jar包
3.创建BookService,BookServiceImpl,BookDao和BookDaoImpl四个类
4.resources下添加spring配置文件,并完成bean的配置
5.使用Spring提供的接口完成IOC容器的创建
6.从容器中获取对象进行方法调用
步骤1:创建Maven项目
步骤2:添加Spring的依赖jar包
pom.xml
1 |
|
步骤3:添加案例中需要的类
创建BookService、BookServiceImpl、BookDao和BookDaoImpl四个类
1 |
|
步骤4:添加spring配置文件
resource下添加spring配置文件applicationContext.xml,并完成bean的配置
步骤5:在配置文件中完成bean配置
1 |
|
步骤6:获取IOC容器
使用Spring提供的接口完成IOC容器的创建,创建App类,编写main方法
1 |
|
步骤7:从容器中获取对象进行方法调用
1 |
|
步骤8:运行程序
Spring的IOC入门案例已经完成,但是在BookServiceImpl
的类中依然存在BookDaoImpl
对象的new操作,它们之间的耦合度还是比较高,这块该如何解决,就需要用到下面的DI:依赖注入
。
DI入门案例
思路分析
- 要想实现依赖注入,必须要基于IOC管理Bean
- DI的入门案例需要依赖于前面的IOC的入门案例
- Service中使用new形式创建的Dao对象是否保留
- 需要删除掉,最终要使用IOC容器中的bean对象
- service中需要的Dao对象如何进入到Service中
- 在service中提供方法,让spring的ioc容器可以通过该方法传入bean对象
- service与Dao间的关系如何描述
- 使用配置文件
代码实现
需求:基于IOC入门案例,在BookServiceImpl类中删除new对象的方式,使用Spring的DI完成Dao层的注入
1.删除业务层中使用new的方式创建的dao对象
2.在业务层提供BookDao的setter方法
3.在配置文件中添加依赖注入的配置
4.运行程序调用方法
步骤1:去除代码中的new
在BookServiceImpl类中,删除业务层中使用new的方式创建的dao对象
1 |
|
步骤2:为属性提供setter方法
在BookServiceImpl类中,为BookDao提供setter方法
1 |
|
步骤3:修改配置完成注入
在配置文件中添加依赖注入的配置
1 |
|
==注意:配置中的两个bookDao的含义是不一样的==
- name=”bookDao”中
bookDao
的作用是让Spring的IOC容器在获取到名称后,将首字母大写,前面加set找对应的setBookDao()
方法进行对象注入 - ref=”bookDao”中
bookDao
的作用是让Spring能在IOC容器中找到id为bookDao
的Bean对象给bookService
进行注入 - 综上所述,对应关系如下:
步骤4:运行程序
IOC相关内容
- bean基础配置
- bean的别名配置
- bean的作用范围配置
bean基础配置(id与class)
1 |
|
思考
- class属性能不能写接口?
- 不能,因为接口是没办法创建对象的
- bean设置id时,id必须唯一,但是如果用于命名习惯而产生了分歧后,该如何解决
- 可以通过取别名的方式去区分
bean的name属性
步骤1:配置别名
打开spring的配置文件applicationContext.xml
1 |
|
步骤2:根据名称容器来获取bean对象
1 |
|
注意事项
bean依赖注入的ref属性指定bean,必须在容器中存在
如果不存在,则会报错,如下
获取bean无论通过id还是name获取,如果无法获取到,将抛出异常NoSuchBeanDefinitionException
bean作用范围scope配置
关于bean的作用范围是bean属性配置的一个==重点==内容。
看到这个作用范围,我们就得思考bean的作用范围是来控制bean哪块内容的?
验证IOC容器中对象是否为单例
验证思路:同一个bean获取两次,将对象打印到控制台,看打印出的地址值是否一致
创建一个AppForScope的类,在其main方法中来验证
1
2
3
4
5
6
7
8
9
10
11public class AppForScope {
public static void main(String[] args) {
ApplicationContext ctx = new
ClassPathXmlApplicationContext("applicationContext.xml");
BookDao bookDao1 = (BookDao) ctx.getBean("bookDao");
BookDao bookDao2 = (BookDao) ctx.getBean("bookDao");
System.out.println(bookDao1);
System.out.println(bookDao2);
}
}打印,观察控制台的打印结果
结论:默认情况下,spring创建的bean对象都是单例的
配置bean为非单例
在Spring配置文件中,配置scope属性来实现bean的非单例创建
在spring的配置文件中,修改bean的scope属性
1
<bean id="bookDao" name="dao" class="com.zhuixun.dao.impl.BookDaoImpl" scope=""/>
将scope设置为singleton,并打印结果(地址值一致)
1
<bean id="bookDao" name="dao" class="com.zhuixun.dao.impl.BookDaoImpl" scope="singleton"/>
将scope设置为prototype,并打印结果(地址值不一致)
1
<bean id="bookDao" name="dao" class="com.zhuixun.dao.impl.BookDaoImpl" scope="prototype"/>
结论:使用bean的scope属性可以控制bean的创建是否为单例:
- singleton默认为单例
- prototype为非单例
scope的后续思考
- 为什么bean默认为单例
- bean为单例的意思是在spring的ioc容器中只会有该类的一个对象
- bean对象只有一个就避免对象的频繁创建与销毁,达到了bean对象的复用,性能高
- bean在容器中是单例的,会不会产生线程安全问题
- 如果对象是有状态对象,即该对象有成员变量可以用来存储数据的,因为所有请求线程共用一个bean对象,所以会存在线程安全问题。
- 如果对象是无状态对象,即该对象没有成员变量没有进行数据存储的,因方法中的局部变量在方法调用完成后会被销毁,所以不会存在线程安全问题。
- 那些bean对象适合交给容器进行管理
- 表现层对象
- 业务层对象
- 数据层对象
- 工具对象
- 那些bean对象不适合交给容器进行管理
- 封装实例的域对象,因为会引发线程安全问题,所以不合适
bean实例化
对象已经能交给Spring的IOC容器来创建了,但是容器是如何来创建对象的呢?
就需要研究下bean的实例化过程
,在这块内容中主要解决两部分内容,分别是
- bean是如何创建的
- 实例化bean的三种方式,
构造方法
,静态工厂
和实例工厂
在讲解这三种创建方式之前,我们需要先确认一件事:
bean本质上就是对象,对象在new的时候会使用构造方法完成,那创建bean也是使用构造方法完成的。
构造方法实例化
步骤1:准备需要被创建的类
准备一个BookDao和BookDaoImpl类
1 |
|
步骤2:将类配置到Spring容器
1 |
|
步骤3:编写运行程序
1 |
|
步骤4:类中提供构造函数测试
在BookDaoImpl类中添加一个无参构造函数,并打印一句话,方便观察结果。
1 |
|
运行程序,如果控制台有打印构造函数中的输出,说明Spring容器在创建对象的时候也走的是构造函数
步骤5:将构造函数改成private测试
1 |
|
运行程序,能执行成功,说明内部走的依然是构造函数,能访问到类中的私有构造方法,显而易见Spring底层用的是反射
步骤6:构造函数中添加一个参数测试
1 |
|
运行程序,程序会报错,说明Spring底层使用的是类的无参构造方法。
错误信息从下往上依次查看,因为上面的错误大都是对下面错误的一个包装,最核心错误是在最下面
静态工厂实例化
工厂方式创建bean
(1)准备一个OrderDao和OrderDaoImpl类
1 |
|
(2)创建一个工厂类OrderDaoFactory并提供一个==静态方法==
1 |
|
(3)编写AppForInstanceOrder运行类,在类中通过工厂获取对象
1 |
|
(4)运行后,可以查看到结果
静态工厂实例化
(1)在spring的配置文件application.properties中添加以下内容:
1 |
|
class:工厂类的类全名
factory-mehod:具体工厂类中创建对象的方法名
对应关系如下图:
(2)在AppForInstanceOrder运行类,使用从IOC容器中获取bean的方法进行运行测试
1 |
|
(3)运行后,可以查看到结果
看到这,可能有人会问了,你这种方式在工厂类中不也是直接new对象的,和我自己直接new没什么太大的区别,而且静态工厂的方式反而更复杂,这种方式的意义是什么?
主要的原因是:
- 在工厂的静态方法中,我们除了new对象还可以做其他的一些业务操作,这些操作必不可少,如:
1 |
|
之前new对象的方式就无法添加其他的业务内容,重新运行,查看结果。这种方式一般是用来兼容早期的一些老系统,所以==了解为主==。
实例工厂与FactoryBean
(1)准备一个UserDao和UserDaoImpl类
1 |
|
(2)创建一个工厂类OrderDaoFactory并提供一个普通方法,注意此处和静态工厂的工厂类不一样的地方是方法不是静态方法
1 |
|
(3)编写AppForInstanceUser运行类,在类中通过工厂获取对象
1 |
|
(4)运行后,可以查看到结果
对于上面这种实例工厂的方式如何交给Spring管理呢?
具体实现步骤为:
(1)在spring的配置文件中添加以下内容:
1 |
|
实例化工厂运行的顺序是:
创建实例化工厂对象,对应的是第一行配置
调用对象中的方法来创建bean,对应的是第二行配置
factory-bean:工厂的实例对象
factory-method:工厂对象中的具体创建对象的方法名,对应关系如下:
factory-mehod:具体工厂类中创建对象的方法名
(2)在AppForInstanceUser运行类,使用从IOC容器中获取bean的方法进行运行测试
1 |
|
(3)运行后,可以查看到结果
实例工厂实例化的方式就已经介绍完了,配置的过程还是比较复杂,所以Spring为了简化这种配置方式就提供了一种叫FactoryBean
的方式来简化开发。
FactoryBean的使用
具体的使用步骤为:
(1)创建一个UserDaoFactoryBean的类,实现FactoryBean接口,重写接口的方法
1 |
|
(2)在Spring的配置文件中进行配置
1 |
|
(3)AppForInstanceUser运行类不用做任何修改,直接运行
这种方式在Spring去整合其他框架的时候会被用到,所以这种方式需要大家理解掌握。
查看源码会发现,FactoryBean接口其实会有三个方法,分别是:
1 |
|
方法一:getObject(),被重写后,在方法中进行对象的创建并返回
方法二:getObjectType(),被重写后,主要返回的是被创建类的Class对象
方法三:没有被重写,因为它已经给了默认值,从方法名中可以看出其作用是设置对象是否为单例,默认true,从意思上来看,我们猜想默认应该是单例,如何来验证呢?
思路很简单,就是从容器中获取该对象的多个值,打印到控制台,查看是否为同一个对象。
1 |
|
通过验证,会发现默认是单例,那如果想改成单例具体如何实现?
只需要将isSingleton()方法进行重写,修改返回为false,即可
1 |
|
从结果中可以看出现在已经是非单例了,但是一般情况下我们都会采用单例,也就是采用默认即可。所以isSingleton()方法一般不需要进行重写。
这些方式中,重点掌握构造方法
和FactoryBean
即可。
需要注意的一点是,构造方法在类中默认会提供,但是如果重写了构造方法,默认的就会消失,在使用的过程中需要注意,如果需要重写构造方法,最好把默认的构造方法也重写下。
bean的生命周期
- 首先理解下什么是生命周期?
- 从创建到消亡的完整过程,例如人从出生到死亡的整个过程就是一个生命周期。
- bean生命周期是什么?
- bean对象从创建到销毁的整体过程。
- bean生命周期控制是什么?
- 在bean创建后到销毁前做一些事情。
现在我们面临的问题是如何在bean的创建之后和销毁之前把我们需要添加的内容添加进去。
bean的生命周期设置
具体的控制有两个阶段:
- bean创建之后,想要添加内容,比如用来初始化需要用到资源
- bean销毁之前,想要添加内容,比如用来释放用到的资源
步骤1:添加初始化和销毁方法
针对这两个阶段,我们在BooDaoImpl类中分别添加两个方法,==方法名任意==
1 |
|
步骤2:配置生命周期
在配置文件添加配置,如下:
1 |
|
步骤3:运行程序
从结果中可以看出,init方法执行了,但是destroy方法却未执行,这是为什么呢?
- Spring的IOC容器是运行在JVM中
- 运行main方法后,JVM启动,Spring加载配置文件生成IOC容器,从容器获取bean对象,然后调方法执行
- main方法执行完后,JVM退出,这个时候IOC容器中的bean还没有来得及销毁就已经结束了
- 所以没有调用对应的destroy方法
close关闭容器
ApplicationContext中没有close方法
需要将ApplicationContext更换成ClassPathXmlApplicationContext
1
2ClassPathXmlApplicationContext ctx = new
ClassPathXmlApplicationContext("applicationContext.xml");调用ctx的close()方法
1
ctx.close();
运行程序,就能执行destroy方法的内容
注册钩子关闭容器
在容器未关闭之前,提前设置好回调函数,让JVM在退出之前回调此函数来关闭容器
调用ctx的registerShutdownHook()方法
1
ctx.registerShutdownHook();
**注意:**registerShutdownHook在ApplicationContext中也没有
运行后,查询打印结果
两种方式介绍完后,close和registerShutdownHook选哪个?
相同点: 这两种都能用来关闭容器
不同点: close()是在调用的时候关闭,registerShutdownHook()是在JVM退出前调用关闭。
分析上面的实现过程,会发现添加初始化和销毁方法,即需要编码也需要配置,实现起来步骤比较多也比较乱。
Spring提供了两个接口来完成生命周期的控制,好处是可以不用再进行配置init-method
和destroy-method
修改BookServiceImpl类,添加两个接口InitializingBean
, DisposableBean
并实现接口中的两个方法afterPropertiesSet
和destroy
1 |
|
重新运行AppForLifeCycle类
小细节
对于InitializingBean接口中的afterPropertiesSet方法,翻译过来为
属性设置之后
。对于BookServiceImpl来说,bookDao是它的一个属性
setBookDao方法是Spring的IOC容器为其注入属性的方法
思考:afterPropertiesSet和setBookDao谁先执行?
从方法名分析,猜想应该是setBookDao方法先执行
验证思路,在setBookDao方法中添加一句话
1
2
3
4
5public void setBookDao(BookDao bookDao) {
System.out.println("set .....");
this.bookDao = bookDao;
}重新运行AppForLifeCycle
得出结论:初始化方法会在类中属性设置之后执行。
DI相关内容
我们先来思考
- 向一个类中传递数据的方式有几种?
- 普通方法(set方法)
- 构造方法
- 依赖注入描述了在容器中建立bean与bean之间的依赖关系的过程,如果bean运行需要的是数字或字符串呢?
- 引用类型
- 简单类型(基本数据类型与String)
Spring就是基于上面这些知识点,为我们提供了两种注入方式,分别是:
- setter注入
- 简单类型
- ==引用类型==
- 构造器注入
- 简单类型
- 引用类型
setter注入
- 在bean中定义引用类型属性,并提供可访问的==set==方法
1 |
|
- 配置中使用==property==标签==ref==属性注入引用类型对象
1 |
|
注入引用数据类型
需求:在bookServiceImpl对象中注入userDao
1.在BookServiceImpl中声明userDao属性
2.为userDao属性提供setter方法
3.在配置文件中使用property标签注入
步骤1:声明属性并提供setter方法
在BookServiceImpl中声明userDao属性,并提供setter方法
1 |
|
步骤2:配置文件中进行注入配置
在applicationContext.xml配置文件中使用property标签注入
1 |
|
步骤3:运行程序
运行AppForDISet类,查看结果,说明userDao已经成功注入
注入简单数据类型
需求:给BookDaoImpl注入一些简单数据类型的数据
参考引用数据类型的注入,我们可以推出具体的步骤为:
1.在BookDaoImpl类中声明对应的简单数据类型的属性
2.为这些属性提供对应的setter方法
3.在applicationContext.xml中配置
思考:
引用类型使用的是<property name="" ref=""/>
,简单数据类型还是使用ref么?
ref是指向Spring的IOC容器中的另一个bean对象的,对于简单数据类型,没有对应的bean对象,该如何配置?
步骤1:声明属性并提供setter方法
在BookDaoImpl类中声明对应的简单数据类型的属性,并提供对应的setter方法
1 |
|
步骤2:配置文件中进行注入配置
在applicationContext.xml配置文件中使用property标签注入
1 |
|
说明:
value:后面跟的是简单数据类型,对于参数类型,Spring在注入的时候会自动转换,但是不能写成
1 |
|
这样的话,spring在将abc
转换成int类型的时候就会报错。
步骤3:运行程序
运行AppForDISet类,查看结果,说明userDao已经成功注入。
注意
两个property注入标签的顺序可以任意。
对于setter注入方式的基本使用就已经介绍完了,
- 对于引用数据类型使用的是
<property name="" ref=""/>
- 对于简单数据类型使用的是
<property name="" value=""/>
构造器注入
构造器注入引用数据类型
需求:将BookServiceImpl类中的bookDao修改成使用构造器的方式注入。
1.将bookDao的setter方法删除掉
2.添加带有bookDao参数的构造方法
3.在applicationContext.xml中配置
步骤1:删除setter方法并提供构造方法
在BookServiceImpl类中将bookDao的setter方法删除掉,并添加带有bookDao参数的构造方法
1 |
|
步骤2:配置文件中进行配置构造方式注入
在applicationContext.xml中配置
1 |
|
说明:
标签
name属性对应的值为构造函数中方法形参的参数名,必须要保持一致。
ref属性指向的是spring的IOC容器中其他bean对象。
步骤3:运行程序
运行AppForDIConstructor类,查看结果,说明bookDao已经成功注入。
构造器注入多个引用数据类型
需求:在BookServiceImpl使用构造函数注入多个引用数据类型,比如userDao
1.声明userDao属性
2.生成一个带有bookDao和userDao参数的构造函数
3.在applicationContext.xml中配置注入
步骤1:提供多个属性的构造函数
在BookServiceImpl声明userDao并提供多个参数的构造函数
1 |
|
步骤2:配置文件中配置多参数注入
在applicationContext.xml中配置注入
1 |
|
**说明:**这两个<contructor-arg>
的配置顺序可以任意
步骤3:运行程序
运行AppForDIConstructor类,查看结果,说明userDao已经成功注入。
构造器注入多个简单数据类型
需求:在BookDaoImpl中,使用构造函数注入databaseName和connectionNum两个参数。
参考引用数据类型的注入,我们可以推出具体的步骤为:
1.提供一个包含这两个参数的构造方法
2.在applicationContext.xml中进行注入配置
步骤1:添加多个简单属性并提供构造方法
修改BookDaoImpl类,添加构造方法
1 |
|
步骤2:配置完成多个属性构造器注入
在applicationContext.xml中进行注入配置
1 |
|
**说明:**这两个<contructor-arg>
的配置顺序可以任意
步骤3:运行程序
运行AppForDIConstructor类,查看结果
问题
上面已经完成了构造函数注入的基本使用,但是会存在一些问题:
- 当构造函数中方法的参数名发生变化后,配置文件中的name属性也需要跟着变
- 这两块存在紧耦合,具体该如何解决?
在解决这个问题之前,需要提前说明的是,这个参数名发生变化的情况并不多,所以上面的还是比较主流的配置方式,下面介绍的,大家都以了解为主。
方式一:删除name属性,添加type属性,按照类型注入
1 |
|
- 这种方式可以解决构造函数形参名发生变化带来的耦合问题
- 但是如果构造方法参数中有类型相同的参数,这种方式就不太好实现了
方式二:删除type属性,添加index属性,按照索引下标注入,下标从0开始
1 |
|
- 这种方式可以解决参数类型重复问题
- 但是如果构造方法参数顺序发生变化后,这种方式又带来了耦合问题
介绍完两种参数的注入方式,具体我们该如何选择呢?
- 强制依赖使用构造器进行,使用setter注入有概率不进行注入导致null对象出现
- 强制依赖指对象在创建的过程中必须要注入指定的参数
- 可选依赖使用setter注入进行,灵活性强
- 可选依赖指对象在创建过程中注入的参数可有可无
- Spring框架倡导使用构造器,第三方框架内部大多数采用构造器注入的形式进行数据初始化,相对严谨
- 如果有必要可以两者同时使用,使用构造器注入完成强制依赖的注入,使用setter注入完成可选依赖的注入
- 实际开发过程中还要根据实际情况分析,如果受控对象没有提供setter方法就必须使用构造器注入
- ==自己开发的模块推荐使用setter注入==
自动配置
什么是依赖自动装配
- IoC容器根据bean所依赖的资源在容器中自动查找并注入到bean中的过程称为自动装配
自动装配的方式有哪些
- ==按类型(常用)==
- 按名称
- 按构造方法
- 不启用自动装配
完成自动装配的配置
自动装配只需要修改applicationContext.xml配置文件即可:
(1)将<property>
标签删除
(2)在<bean>
标签中添加autowire属性
首先来实现按照类型注入的配置
1 |
|
==注意事项:==
- 需要注入属性的类中对应属性的setter方法不能省略
- 被注入的对象必须要被Spring的IOC容器管理
- 按照类型在Spring的IOC容器中如果找到多个对象,会报
NoUniqueBeanDefinitionException
一个类型在IOC中有多个对象,还想要注入成功,这个时候就需要按照名称注入,配置方式为:
1 |
|
==注意事项:==
按照名称注入中的名称指的是什么?
自动装配只需要修改applicationContext.xml配置文件即可:
(1)将
<property>
标签删除(2)在
<bean>
标签中添加autowire属性首先来实现按照类型注入的配置
1
2
3
4
5
6
7
8
9
10<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean class="com.itheima.dao.impl.BookDaoImpl"/>
<!--autowire属性:开启自动装配,通常使用按类型装配-->
<bean id="bookService" class="com.itheima.service.impl.BookServiceImpl" autowire="byType"/>
</beans>==注意事项:==
- 需要注入属性的类中对应属性的setter方法不能省略
- 被注入的对象必须要被Spring的IOC容器管理
- 按照类型在Spring的IOC容器中如果找到多个对象,会报
NoUniqueBeanDefinitionException
一个类型在IOC中有多个对象,还想要注入成功,这个时候就需要按照名称注入,配置方式为:
1
2
3
4
5
6
7
8
9
10<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean class="com.itheima.dao.impl.BookDaoImpl"/>
<!--autowire属性:开启自动装配,通常使用按类型装配-->
<bean id="bookService" class="com.itheima.service.impl.BookServiceImpl" autowire="byName"/>
</beans>==注意事项:==
按照名称注入中的名称指的是什么?
bookDao是private修饰的,外部类无法直接方法
外部类只能通过属性的set方法进行访问
对外部类来说,setBookDao方法名,去掉set后首字母小写是其属性名
- 为什么是去掉set首字母小写?
- 这个规则是set方法生成的默认规则,set方法的生成是把属性名首字母大写前面加set形成的方法名
所以按照名称注入,其实是和对应的set方法有关,但是如果按照标准起名称,属性名和set对应的名是一致的
如果按照名称去找对应的bean对象,找不到则注入Null
当某一个类型在IOC容器中有多个对象,按照名称注入只找其指定名称对应的bean对象,不会报错
两种方式介绍完后,以后用的更多的是==按照类型==注入。
最后对于依赖注入,需要注意一些其他的配置特征:
- 自动装配用于引用类型依赖注入,不能对简单类型进行操作
- 使用按类型装配时(byType)必须保障容器中相同类型的bean唯一,推荐使用
- 使用按名称装配时(byName)必须保障容器中具有指定名称的bean,因变量名与配置耦合,不推荐使用
- 自动装配优先级低于setter注入与构造器注入,同时出现时自动装配配置失效
集合注入
注入数组类型数据
1 |
|
注入List类型数据
1 |
|
注入set类型数据
1 |
|
注入Properties类型数据
1 |
|
说明:
- property标签表示setter方式注入,构造方式注入constructor-arg标签内部也可以写
<array>
、<list>
、<set>
、<map>
、<props>
标签 - List的底层也是通过数组实现的,所以
<list>
和<array>
标签是可以混用 - 集合中要添加引用类型,只需要把
<value>
标签改成<ref>
标签,这种方式用的比较少
IOC/DI配置第三方bean
案例:数据源对象管理
环境准备
创建一个Maven项目
pom.xml添加依赖
1
2
3
4
5
6
7<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.2.10.RELEASE</version>
</dependency>
</dependencies>resources下添加spring的配置文件applicationContext.xml
1
2
3
4
5
6
7
8<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>编写一个运行类App
1
2
3
4
5public class App {
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml");
}
}
思路分析
需求:使用spring的IOC容器来管理Druid连接池对象
- 使用第三方技术,需要在pom.xml添加依赖
- 在配置文件中将第三方的类(要使用的第三方的类,这里指的是DruidDataSource)制作成一个bean,让IOC进行管理
- 数据库连接需要基础的四要素
驱动
、连接
、用户名
、密码
,如何注入到对应的bean中(查看对应的DruidDataSource类的源码,可以发现使用的是setter注入)- 从IOC容器中获取对应的bean对象,将其打印到控制台查看结果
实现Druid管理
步骤1:导入Druid依赖
pom.xml中添加依赖
1 |
|
步骤2:配置第三方bean
在applicationContext.xml配置文件中添加DruidDataSource的配置
1 |
|
步骤3:从IOC容器中获取对应的bean对象
1 |
|
步骤4:运行程序
注意
数据连接池在配置属性的时候,除了可以注入数据库连接四要素外还可以配置很多其他的属性,具体都有哪些属性用到的时候再去查,一般配置基础的四个,其他都有自己的默认值
Druid和C3P0在没有导入mysql驱动包的前提下,一个没报错一个报错,说明Druid在初始化的时候没有去加载驱动,而C3P0刚好相反
Druid程序运行虽然没有报错,但是当调用DruidDataSource的getConnection()方法获取连接的时候,也会报找不到驱动类的错误
所以还需要导入对应的驱动类
1
2
3
4
5<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.47</version>
</dependency>
加载properties文件
- 使用到了一些固定常量,如数据库连接四要素,把这些值写在spring的配置文件中不利于后期维护
- 需要将这些值提取到一个外部的properties配置文件中,然后spring从配置文件中读取对应的属性值来进行配置
第三方bean属性优化
需求:将数据库连接四要素提取到properties配置文件,spring来加载配置信息并使用这些信息来完成属性注入。
1.在resources下创建一个jdbc.properties(文件的名称可以任意)
2.将数据库连接四要素配置到配置文件中
3.在Spring的配置文件中加载properties文件
4.使用加载到的值实现属性注入
步骤1:在resources下创建一个jdbc.properties文件,并添加对应的属性键值对
步骤2:在applicationContext.xml中开启context命名空间
1
2
3
4
5
6
7
8
9
10<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd">
</beans>步骤3:在配置文件中使用context,命名空间下的标签来加载properties配置文件
1
<context:property-placeholder location="jdbc.properties"/>
步骤4:使用${key}来读取properties配置文件的内容并完成属性注入
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd">
<context:property-placeholder location="jdbc.properties"/>
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
<property name="driverClassName" value="${jdbc.driver}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
</beans>
注意
<context:property-placeholder/>
标签会加载系统的环境变量,而且环境变量的值会被优先加载,所以导致自己设置的键名和系统环境冲突的话,会优先加载系统变量,给标签添加system-properties-mode:设置为NEVER,表示不加载系统属性。查看系统的环境变量
1
2
3
4public static void main(String[] args) throws Exception{
Map<String, String> env = System.getenv();
System.out.println(env);
}当有多个properties配置文件需要被加载,该如何配置
1
2
3
4
5
6
7
8<!--方式一 -->
<context:property-placeholder location="jdbc.properties,jdbc2.properties" system-properties-mode="NEVER"/>
<!--方式二-->
<context:property-placeholder location="*.properties" system-properties-mode="NEVER"/>
<!--方式三 -->
<context:property-placeholder location="classpath:*.properties" system-properties-mode="NEVER"/>
<!--方式四-->
<context:property-placeholder location="classpath*:*.properties" system-properties-mode="NEVER"/>- 方式1:可以实现,如果配置文件多的话,每个都需要配置
- 方式2:*.properties,代表所有以properties结尾的文件都会被加载,可以解决方式一的问题,但是不标准
- 方式3:标准写法,classpath:代表的是从根路径下开始查找,但是只能查询当前项目的根路径
- 方式4:不仅可以加载当前项目还可以加载当前项目所依赖的所有项目的根路径下的properties配置文件
小结
如何开启context命名空间
如何加载properties配置文件
1
<context:property-placeholder location="" system-properties-mode="NEVER"/>
如何在applicationContext.xml引入properties配置文件中的值
1
${key}
核心容器
这里所说的核心容器,可以把它简单的理解为
ApplicationContext
,前面虽然已经用到过,但是并没有系统的学习,接下来咱们从以下几个问题入手来学习下容器的相关知识:
- 如何创建容器?
- 创建好容器后,如何从容器中获取bean对象?
- 容器类的层次结构是什么?
- BeanFactory是什么?
容器的创建方式
类路径下的xml配置文件
1 |
|
文件系统下的XML配置文件
这种方式是从项目路径下开始查找applicationContext.xml
配置文件的.
这种方式虽能实现,但是当项目的位置发生变化后,代码也需要跟着改,耦合度较高,不推荐使用。
1 |
|
Bean的三种获取方式
getBean(“名称”),这种方式存在的问题就是每次获取的时候需要进行类型转换
1
BookDao bookDao = (BookDao) ctx.getBean("bookDao");
getBean(“名称”,类型.class),这种方式可以解决类型强转问题,但是参数又多加了一个,相对来说没有简化多少
1
BookDao bookDao = ctx.getBean("bookDao",BookDao.class);
getBean(类型.class),这种方式类似依赖注入中的按类型注入,必须要保证IOC容器中该类型对应的bean对象只能有一个
1
BookDao bookDao = ctx.getBean(BookDao.class);
容器类层次结构
在IDEA中双击shift,输入BeanFactory(容器的最上级的父接口)
点击进入BeanFactory类,ctrl+h,就能查看到如下结构的层次关系
从图中可以看出,容器类也是从无到有,根据需要一层层叠加上来的,大家重点理解下这种设计思想。
BeanFactory的使用
使用BeanFactory来创建IOC容器的具体实现方式为:
1 |
|
为了更好的看出BeanFactory
和ApplicationContext
之间的区别,在BookDaoImpl添加如下构造函数:
1 |
|
如果不去获取bean对象,打印会发现:
BeanFactory是延迟加载,只有在获取bean对象的时候才会去创建
ApplicationContext是立即加载,容器加载的时候就会创建bean对象
ApplicationContext要想成为延迟加载,只需要按照如下方式进行配置
1
<bean id="bookDao" class="com.zhuixun.dao.impl.BookDaoImpl" lazy-init="true"/>
ApplicationContext和BeanFactory区别
- BeanFactory是IoC容器的顶层接口,初始化BeanFactory对象时,加载的bean延迟加载
- ApplicationContext接口是Spring容器的核心接口,初始化时bean立即加载
- ApplicationContext接口提供基础的bean操作相关方法,通过其他接口扩展其功能
ApplicationContext接口常用初始化类
ClassPathXmlApplicationContext(常用)
FileSystemXmlApplicationContext
bean相关
依赖注入相关
IOC/DI注解开发
要想真正简化开发,就需要用到Spring的注解开发,Spring对注解支持的版本历程:
- 2.0版开始支持注解
- 2.5版注解功能趋于完善
- 3.0版支持纯注解开发
注解开发定义bean
步骤1:删除原XML配置
将配置文件中的
1 |
|
步骤2:Dao上添加注解
在BookDaoImpl类上添加@Component
注解
1 |
|
注意:@Component注解不可以添加在接口上,因为接口是无法创建对象的
xml与注解配置对应的关系:
步骤3:配置spring的注解包扫描
为了让Spring框架能够扫描到写在类上的注解,需要在配置文件上进行包扫描
1 |
|
说明
component-scan
- component:组件,Spring将管理的bean视作自己的一个组件
- scan:扫描
base-package指定Spring框架扫描的包路径,它会扫描指定包及其子包中的所有类上的注解。
- 包路径越多[如:com.zhuixun.dao.impl],扫描的范围越小速度越快
- 包路径越少[如:com.zhuixun],扫描的范围越大速度越慢
- 一般扫描到项目的组织名称即Maven的groupId下[如:com.zhuixun]即可。
步骤4:service上添加注解
在BookServiceImpl类上也添加@Component
交给Spring框架管理
1 |
|
步骤5:运行程序
1 |
|
说明
BookServiceImpl类没有起名称,所以在App中是按照类型来获取bean对象
@Component注解如果不起名称,会有一个默认值就是
当前类名首字母小写
,所以也可以按照名称获取,如1
2BookService bookService = (BookService)ctx.getBean("bookServiceImpl");
System.out.println(bookService);
对于@Component注解,还衍生出了其他三个注解@Controller
、@Service
、@Repository
通过查看源码会发现:
这三个注解和@Component注解的作用是一样的,衍生出这三个的原因是:方便我们后期在编写类的时候能很好的区分出这个类是属于表现层
、业务层
还是数据层
的类。
纯注解开发模式
spring3.0开启了纯注解开发模式,使用Java类替代配置文件,开启了Spring快速开发赛道
实现思路为:
- 将配置文件applicationContext.xml删除掉,使用类来替换。
步骤1:创建配置类
创建一个配置类SpringConfig
1 |
|
步骤2:标识该类为配置类
在配置类添加@Configuration注解,将其标识为一个配置类,替换applicationContext.xml
1 |
|
步骤3:用注解替换包扫描配置
在配置类上添加包扫描注解@ComponentScan
替换<context:component-scan base-package=""/>
1 |
|
步骤4:创建运行类并执行
创建一个新的运行类AppForAnnotation
1 |
|
注解模式下Bean的作用范围
创建运行类App
1
2
3
4
5
6
7
8
9public class App {
public static void main(String[] args) {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(SpringConfig.class);
BookDao bookDao1 = ctx.getBean(BookDao.class);
BookDao bookDao2 = ctx.getBean(BookDao.class);
System.out.println(bookDao1);
System.out.println(bookDao2);
}
}先运行App类,在控制台打印两个一摸一样的地址,说明默认情况下bean是单例
要想将BookDaoImpl变成非单例,只需要在其类上添加
@scope
注解1
2
3
4
5
6
7
8
9@Repository
//@Scope设置bean的作用范围
@Scope("prototype")
public class BookDaoImpl implements BookDao {
public void save() {
System.out.println("book dao save ...");
}
}
注解模式下Bean的生命周期
在BookDaoImpl中添加两个方法,
init
和destroy
,方法名可以任意1
2
3
4
5
6
7
8
9
10
11
12@Repository
public class BookDaoImpl implements BookDao {
public void save() {
System.out.println("book dao save ...");
}
public void init() {
System.out.println("init ...");
}
public void destroy() {
System.out.println("destroy ...");
}
}在对应的方法上添加
@PostConstruct
和@PreDestroy
注解即可。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15@Repository
public class BookDaoImpl implements BookDao {
public void save() {
System.out.println("book dao save ...");
}
@PostConstruct //在构造方法之后执行,替换 init-method
public void init() {
System.out.println("init ...");
}
@PreDestroy //在销毁方法之前执行,替换 destroy-method
public void destroy() {
System.out.println("destroy ...");
}
}要想看到两个方法执行,需要注意的是
destroy
只有在容器关闭的时候,才会执行,所以需要修改App的类1
2
3
4
5
6
7
8
9
10public class App {
public static void main(String[] args) {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(SpringConfig.class);
BookDao bookDao1 = ctx.getBean(BookDao.class);
BookDao bookDao2 = ctx.getBean(BookDao.class);
System.out.println(bookDao1);
System.out.println(bookDao2);
ctx.close(); //关闭容器
}
}
注意
@PostConstruct和@PreDestroy注解如果找不到,需要导入下面的jar包
1
2
3
4
5<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.2</version>
</dependency>找不到的原因是,从JDK9以后jdk中的javax.annotation包被移除了,这两个注解刚好就在这个包中。
小结
注解开发依赖注入
Spring为了使用注解简化开发,并没有提供构造函数注入
、setter注入
对应的注解,只提供了自动装配的注解实现。
注解实现按照类型注入
在BookServiceImpl类的bookDao属性上添加@Autowired
注解
1 |
|
注意
- @Autowired可以写在属性上,也可也写在setter方法上,最简单的处理方式是
写在属性上并将setter方法删除掉
- 为什么setter方法可以删除呢?
- 自动装配基于反射设计创建对象并通过暴力反射为私有属性进行设值
- 普通反射只能获取public修饰的内容
- 暴力反射除了获取public修饰的内容还可以获取private修改的内容
- 所以此处无需提供setter方法
注解实现按照名称注入
当根据类型在容器中找到多个bean,注入参数的属性名又和容器中bean的名称不一致,这个时候该如何解决,就需要使用到@Qualifier
来指定注入哪个名称的bean对象。
1 |
|
@Qualifier注解后的值就是需要注入的bean的名称。
注意:@Qualifier不能独立使用,必须和@Autowired一起使用
简单数据类型注入
引用类型看完,简单类型注入就比较容易懂了。简单类型注入的是基本数据类型或者字符串类型,下面在BookDaoImpl
类中添加一个name
属性,用其进行简单类型注入
1 |
|
数据类型换了,对应的注解也要跟着换,这次使用@Value
注解,将值写入注解的参数中就行了
1 |
|
注解读取properties配置文件
@Value
一般会被用在从properties配置文件中读取内容进行使用
在resource下准备properties文件
使用注解加载properties配置文件(在配置类上添加@PropertySource注解)
1
2
3
4
5@Configuration
@ComponentScan("com.zhuixun")
@PropertySource("jdbc.properties")
public class SpringConfig {
}使用@Value读取配置文件中的内容
1
2
3
4
5
6
7
8@Repository("bookDao")
public class BookDaoImpl implements BookDao {
@Value("${name}")
private String name;
public void save() {
System.out.println("book dao save ..." + name);
}
}运行程序
注意
如果读取的properties配置文件有多个,可以使用
@PropertySource
的属性来指定多个1
@PropertySource({"jdbc.properties","xxx.properties"})
@PropertySource
注解属性中不支持使用通配符*
,运行会报错1
@PropertySource({"*.properties"})
@PropertySource
注解属性中可以把classpath:
加上,代表从当前项目的根路径找文件1
@PropertySource({"classpath:jdbc.properties"})
IOC/DI注解开发管理第三方bean
前面定义bean的时候都是在自己开发的类上面写个注解就完成了,但如果是第三方的类,这些类都是在jar包中,我们没有办法在类上面添加注解。遇到上述问题,我们就需要有一种更加灵活的方式来定义bean,这种方式不能在原始代码上面书写注解,一样能定义bean,这就用到了一个全新的注解@Bean
对Druid
数据源的管理,具体的实现步骤为:
步骤1:导入对应的jar包
1 |
|
步骤2:在配置类中添加一个方法
注意该方法的返回值就是有要创建的Bean对象类型
1 |
|
步骤3:在方法上添加@Bean注解
@Bean注解的作用是将方法的返回值制作为Spring管理的一个bean对象
1 |
|
步骤4:从IOC容器获取对象并打印
1 |
|
如果有多个bean要被Spring管理,直接在配置类中多些几个方法,方法上添加@Bean注解即可。
引入外部配置类
如果把所有的第三方bean都配置到Spring的配置类SpringConfig
中,虽然可以,但是不利于代码阅读和分类管理,所以我们应该把每个第三方bean都生成一个对应的配置类
1 |
|
使用包扫描引入
在Spring的配置类上添加包扫描
1
2
3
4
5@Configuration
@ComponentScan("com.zhuixun.config")
public class SpringConfig {
}在JdbcConfig上添加配置注解
JdbcConfig类要放入到
com.zhuixun.config
包下,需要被Spring的配置类扫描到即可运行程序
这种方式虽然能够扫描到,但是不能很快的知晓都引入了哪些配置类,所有这种方式不推荐使用。
使用@Import引入
在Spring配置类上使用@Import
注解手动引入需要加载的配置类
去除JdbcConfig类上的注解
在Spring配置类中引入
1
2
3
4
5
6@Configuration
//@ComponentScan("com.itheima.config")
@Import({JdbcConfig.class})
public class SpringConfig {
}注意
扫描注解可以移除
@Import参数需要的是一个数组,可以引入多个配置类。
@Import注解在配置类中只能写一次
注解开发为第三方注入资源
简单数据类型
类中提供四个属性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15public class JdbcConfig {
private String driver;
private String url;
private String userName;
private String password;
@Bean
public DataSource dataSource(){
DruidDataSource ds = new DruidDataSource();
ds.setDriverClassName("com.mysql.jdbc.Driver");
ds.setUrl("jdbc:mysql://localhost:3306/spring_db");
ds.setUsername("root");
ds.setPassword("root");
return ds;
}
}使用@value注解引入值
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19public class JdbcConfig {
@Value("com.mysql.jdbc.Driver")
private String driver;
@Value("jdbc:mysql://localhost:3306/spring_db")
private String url;
@Value("root")
private String userName;
@Value("password")
private String password;
@Bean
public DataSource dataSource(){
DruidDataSource ds = new DruidDataSource();
ds.setDriverClassName(driver);
ds.setUrl(url);
ds.setUsername(userName);
ds.setPassword(password);
return ds;
}
}上述也可以通过读取properties文件后,在通过${key}赋值
引用数据类型
在SpringConfig中扫描BookDao。扫描的目的是让Spring能管理到BookDao,也就是说让IOC容器中有一个bookDao对象
1
2
3
4
5@Configuration
@ComponentScan("com.zhuixun.dao")
@Import({JdbcConfig.class})
public class SpringConfig {
}在JdbcConfig类的方法上添加参数
1
2
3
4
5
6
7
8
9
10@Bean
public DataSource dataSource(BookDao bookDao){
System.out.println(bookDao);
DruidDataSource ds = new DruidDataSource();
ds.setDriverClassName(driver);
ds.setUrl(url);
ds.setUsername(userName);
ds.setPassword(password);
return ds;
}引用类型注入只需要为bean定义方法设置形参即可,容器会根据类型自动装配对象
注解开发总结
Spring整合Junit
步骤1:引入依赖
1 |
|
步骤2:编写测试类
在test\java下创建一个AccountServiceTest,这个名字任意
1 |
|
注意
- 单元测试,如果测试的是注解配置类,则使用
@ContextConfiguration(classes = 配置类.class)
- 单元测试,如果测试的是配置文件,则使用
@ContextConfiguration(locations={配置文件名,...})
- Junit运行后是基于Spring环境运行的,所以Spring提供了一个专用的类运行器,这个务必要设置,这个类运行器就在Spring的测试专用包中提供的,导入的坐标就是这个东西
SpringJUnit4ClassRunner
- 上面两个配置都是固定格式,当需要测试哪个bean时,使用自动装配加载对应的对象,下面的工作就和以前做Junit单元测试完全一样了
知识点1:@RunWith
名称 | @RunWith |
---|---|
类型 | 测试类注解 |
位置 | 测试类定义上方 |
作用 | 设置JUnit运行器 |
属性 | value(默认):运行所使用的运行期 |
知识点2:@ContextConfiguration
名称 | @ContextConfiguration |
---|---|
类型 | 测试类注解 |
位置 | 测试类定义上方 |
作用 | 设置JUnit加载的Spring核心配置 |
属性 | classes:核心配置类,可以使用数组的格式设定加载多个配置类 locations:配置文件,可以使用数组的格式设定加载多个配置文件名称 |
AOP简介
AOP(Aspect Oriented Programming)面向切面编程,一种编程范式,指导开发者如何组织程序结构。
AOP是在不改原有代码的前提下对其进行增强
AOP核心概念
为了能更好的理解AOP的相关概念,准备了一个环境,整个环境的内容我们暂时可以不用关注,最主要的类为:BookDaoImpl
1 |
|
- spring的aop是对一个类的方法在不进行任何修改的前提下实现增强,对于上述案例中BookServiceImpl中有save、update、delete、select方法,这些方法我们给起了一个名字叫
连接点
- 在BookServiceImpl的四个方法中,update和delete只有打印,没有计算万次执行消耗时间,但是在运行的时候已经有改功能,那就是说update和delete方法都已经被增强,所以对于需要增强的方法我们叫做
切入点
- 执行BookServiceImpl的update和delete方法的时候都被添加了一个计算万次执行消耗时间的功能,将这个功能抽取到一个方法中,换句话说就是存放共性功能的方法,我们给起了个名字叫
通知
- 通知是要增强的内容,会有多个,切入点是需要被增强的方法,也有有多个,到哪个切入点需要添加哪个通知,就需要提钱将它们之间的关系描述清楚,对于通知和切入点之间的关系描述,我们叫做
切面
- 通知是一个方法,方法不能独立存在,需要被写在一个类中,这个类叫做
通知类
总结
连接点(JoinPoint)
程序执行过程中的任意位置,粒度为执行方法,抛出异常、设置变量等
- 在SpringAOP中,理解为方法的执行
切入点(Pointcut)
匹配连接点的式子
在SpringAOP中,一个切入点可以描述一个具体方法、也可以匹配多个方法
连接点范围要比切入点范围大,是切入点的方法也一定是连接点,但是是连接点的方法不一定要被增强,所以可能不是切入点
通知(Advice)
在切入点执行的操作,也就是共性功能
- 在SpringAOP中,功能最终以方法的形式呈现
通知类
定义通知的类
切面(Aspect)
描述通知与切入点的对应关系
AOP入门案例
思路分析
1.导入坐标(pom.xml)
2.制作连接点(原始操作,Dao接口与实现类)
3.制作共性功能(通知类与通知)
4.定义切入点
5.绑定切入点与通知关系(切面)
环境准备
创建一个Maven项目
pom.xml添加Spring依赖
1
2
3
4
5
6
7<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.2.10.RELEASE</version>
</dependency>
</dependencies>添加BookDao和BookDaoImpl类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17public interface BookDao {
public void save();
public void update();
}
@Repository
public class BookDaoImpl implements BookDao {
public void save() {
System.out.println(System.currentTimeMillis());
System.out.println("book dao save ...");
}
public void update(){
System.out.println("book dao update ...");
}
}创建Spring配置类
1
2
3
4@Configuration
@ComponentScan("com.zhuixun")
public class SpringConfig {
}编写App运行类
1
2
3
4
5
6
7public class App {
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(SpringConfig.class);
BookDao bookDao = ctx.getBean(BookDao.class);
bookDao.save();
}
}
说明
- 目前打印save方法的时候,因为方法中有打印系统时间,所以运行的时候是可以看到系统时间
- 对于update方法来说,就没有该功能
- 我们要使用SpringAOP的方式在不改变update方法的前提下让其具有打印系统时间的功能。
AOP实现步骤
步骤1:添加依赖
1 |
|
- 因为
spring-context
中已经导入了spring-aop
,所以不需要再单独导入spring-aop
- 导入AspectJ的jar包,AspectJ是AOP思想的一个具体实现,Spring有自己的AOP实现,但是相比于AspectJ来说比较麻烦,所以我们直接采用Spring整合ApsectJ的方式进行AOP开发。
步骤2:定义接口与实现类
1 |
|
步骤3:定义通知类和通知
通知就是将共性功能抽取出来后形成的方法,共性功能指的就是当前系统时间的打印。类名和方法名没有要求,可以任意。
1 |
|
步骤4:定义切入点
BookDaoImpl中有两个方法,分别是save和update,我们要增强的是update方法
1 |
|
说明
- 切入点定义依托一个不具有实际意义的方法进行,即无参数、无返回值、方法体无实际逻辑。
- execution及后面编写的内容,后面会讲解。
步骤5:制作切面
切面是用来描述通知和切入点之间的关系
1 |
|
步骤6:将通知类配给容器并标识其为切面
1 |
|
步骤7:开启注解格式AOP功能
1 |
|
步骤8:运行程序
1 |
|
AOP工作流程
由于AOP是基于Spring容器管理的bean做的增强,所以整个工作过程需要从Spring加载bean说起
流程1:Spring容器启动
- 容器启动就需要加载bean,那些类需要被加载
- 需要被增强的类,如BookServiceImpl
- 通知类:如MyAdvice
- 注意此时bean对象还没有创建成功
流程2:读取所有切面配置中的切入点
- 上面这个例子中有两个切入点的配置,但是第一个
ptx()
并没有被使用,所以不会被读取。
流程3:初始化bean
判定bean对应的类中的方法是否匹配到任意切入点
注意第一步在容器启动的时候,bean对象还没有创建成功
要被实例化bean对象的类中的方法和切入点进行匹配
- 匹配失败,创建原始对象,如UserDao
- 匹配失败说明不需要增强,直接调用原始对象的方法即可
- 匹配成功,创建原始对象(目标对象)的代理对象,如:BookDao
- 匹配成功说明需要对其进行增强
- 对哪个类做增强,这个类对应的对象就叫做目标对象
- 因为要对目标对象进行功能增强,而采用的技术是动态代理,所以会为其创建一个代理对象
- 最终运行的是代理对象的方法,在该方法中会对原始方法进行功能增强
- 匹配失败,创建原始对象,如UserDao
流程4:获取bean执行方法
- 获取的bean是原始对象时,调用方法并执行,完成操作
- 获取的bean是代理对象时,根据代理对象的运行模式运行原始方法与增强的内容,完成操作。
验证容器中是否为代理对象
为了验证IOC容器中创建的对象和我们刚才所说的结论是否一致,首先先把结论理出来:
- 如果目标对象中的方法会被增强,那么容器中将存入的是目标对象的代理对象
- 如果目标对象中的方法不被增强,那么容器中将存入的是目标对象本身。
AOP核心概念
- 目标对象(Target):原始功能去掉共性功能对应的类产生的对象,这种对象是无法直接完成最终工作的
- 代理(Proxy):目标对象无法直接完成工作,需要对其进行功能回填,通过原始对象的代理对象实现
目标对象就是要增强的类[如:BookServiceImpl类]对应的对象,也叫原始对象,不能说它不能运行,只能说它在运行的过程中对于要增强的内容是缺失的。
SpringAOP是在不改变原有设计(代码)的前提下对其进行增强的,它的底层采用的是代理模式实现的,所以要对原始对象进行增强,就需要对原始对象创建代理对象,在代理对象中的方法把通知[如:MyAdvice中的method方法]内容加进去,就实现了增强,这就是我们所说的代理(Proxy)。
SpringAOP的本质或者可以说底层实现是通过代理模式
AOP配置管理
AOP切入点表达式
- 语法格式
- 通配符
- 书写技巧
语法格式
首先我们先要明确两个概念:
- 切入点:要进行增强的方法
- 切入点表达式:要进行增强的方法的描述方式
对于切入点的描述,有以下两种方式
描述方式1
执行com.zhuixun.dao包下的BookDao接口中的无参数update方法
1
execution(void com.zhuixun.dao.BookDao.update())
描述方法2
执行com.zhuixun.dao.impl包下的BookDaoImpl类中的无参数update方法
1
execution(void com.zhuixun.dao.impl.BookDaoImpl.update())
因为调用接口方法的时候最终运行的还是其实现类的方法,所以上面两种描述方式都是可以的。
对于切入点表达式的语法为:
切入点表达式标准格式:动作关键字(访问修饰符 返回值 包名.类/接口名.方法名(参数) 异常名)
1
execution(public User com.zhuixun.service.UserService.findById(int))
- execution:动作关键字,描述切入点的行为动作,例如execution表示执行到指定切入点
- public:访问修饰符,还可以是public,private等,可以省略
- User:返回值,写返回值类型
- com.zhuixun.service:包名,多级包使用点连接
- UserService:类/接口名称
- findById:方法名
- int:参数,直接写参数的类型,多个类型用逗号隔开
- 异常名:方法定义中抛出指定异常,可以省略
切入点表达式就是要找到需要增强的方法,所以它就是对一个具体方法的描述,但是方法的定义会有很多,所以如果每一个方法对应一个切入点表达式想想这块就会觉得将来编写起来会比较麻烦,需要用到通配符
通配符
我们使用通配符描述切入点,主要的目的就是简化之前的配置
*
:单个独立的任意符号,可以独立出现,也可以作为前缀或者后缀的匹配符出现1
execution(public * com.zhuixun.*.UserService.find*(*))
匹配com.zhuixun包下的任意包中的UserService类或接口中所有find开头的带有一个参数的方法
..
:多个连续的任意符号,可以独立出现,常用于简化包名与参数的书写1
execution(public User com..UserService.findById(..))
匹配com包下的任意包中的UserService类或接口中所有名称为findById的方法
+
:专用于匹配子类类型1
execution(* *..*Service+.*(..))
这个使用率较低,描述子类的,咱们做JavaEE开发,继承机会就一次,使用都很慎重,所以很少用它。*Service+,表示所有以Service结尾的接口的子类。
接下来,我们把案例中使用到的切入点表达式来分析下:
1 |
|
书写技巧
- 所有代码按照标准规范开发,否则以下技巧全部失效
- 描述切入点通常描述接口,而不描述实现类,如果描述到实现类,就出现紧耦合了
- 访问控制修饰符针对接口开发均采用public描述(可省略访问控制修饰符描述)
- 返回值类型对于增删改类使用精准类型加速匹配,对于查询类使用*通配快速描述
- 包名书写尽量不使用..匹配,效率过低,常用*做单个包描述匹配,或精准匹配
- 接口名/类名书写名称与模块相关的采用*匹配,例如UserService书写成*Service,绑定业务层接口名
- 方法名书写以动词进行精准匹配,名词采用匹配,例如getById书写成getBy,selectAll书写成selectAll
- 参数规则较为复杂,根据业务方法灵活调整
- 通常不使用异常作为匹配规则
AOP通知类型
- 前置通知
- 后置通知
- 环绕通知(重点)
- 返回后通知(了解)
- 抛出异常后通知(了解)
前置通知,追加功能到方法执行前,类似于在代码1或者代码2添加内容
后置通知,追加功能到方法执行后,不管方法执行的过程中有没有抛出异常都会执行,类似于在代码5添加内容
返回后通知,追加功能到方法执行后,只有方法正常执行结束后才进行,类似于在代码3添加内容,如果方法执行抛出异常,返回后通知将不会被添加
抛出异常后通知,追加功能到方法抛出异常后,只有方法执行出异常才进行,类似于在代码4添加内容,只有方法抛出异常后才会被添加
环绕通知,环绕通知功能比较强大,它可以追加功能到方法执行的前后,这也是比较常用的方式,它可以实现其他四种通知类型的功能,具体是如何实现的,需要我们往下学习。
环绕通知是如何实现其他通知类型的功能
因为环绕通知是可以控制原始方法执行的,所以我们把增强的代码写在调用原始方法的不同位置就可以实现不同的通知类型的功能
环绕通知注意事项
- 环绕通知必须依赖形参ProceedingJoinPoint才能实现对原始方法的调用,进而实现原始方法调用前后同时添加通知
- 通知中如果未使用ProceedingJoinPoint对原始方法进行调用将跳过原始方法的执行
- 对原始方法的调用可以不接收返回值,通知方法设置成void即可,如果接收返回值,最好设定为Object类型
- 原始方法的返回值如果是void类型,通知方法的返回值类型可以设置成void,也可以设置成Object
- 由于无法预知原始方法运行后是否会抛出异常,因此环绕通知方法必须要处理Throwable异常
AOP事务管理
- 事务作用:在数据层保障一系列的数据库操作同成功同失败
- Spring事务作用:在数据层或业务层保障一系列的数据库操作同成功同失败
数据层有事务我们可以理解,为什么业务层也需要处理事务呢?
举个简单的例子,
- 转账业务会有两次数据层的调用,一次是加钱一次是减钱
- 把事务放在数据层,加钱和减钱就有两个事务
- 没办法保证加钱和减钱同时成功或者同时失败
- 这个时候就需要将事务放在业务层进行处理。
Spring为了管理事务,提供了一个平台事务管理器PlatformTransactionManager
,commit是用来提交事务,rollback是用来回滚事务。
PlatformTransactionManager只是一个接口,Spring还为其提供了一个具体的实现:DataSourceTransactionManager事务管理器
转账案例
需求: 实现任意两个账户间转账操作
需求微缩: A账户减钱,B账户加钱
为了实现上述的业务需求,我们可以按照下面步骤来实现下:
①:数据层提供基础操作,指定账户减钱(outMoney),指定账户加钱(inMoney)
②:业务层提供转账操作(transfer),调用减钱与加钱的操作
③:提供2个账号和操作金额执行转账操作
④:基于Spring整合MyBatis环境搭建上述操作
事务管理
这里就跳过环境搭建,如果在转账的过程中出现了异常
1 |
|
会出现这个情况:程序出现异常后,转账失败,但是异常之前操作成功,异常之后操作失败,整体业务失败。
当程序出问题后,我们需要让事务进行回滚,而且这个事务应该是加在业务层上,而Spring的事务管理就是用来解决这类问题的
步骤1:在需要被事务管理的方法上添加注解
1 |
|
@Transactional可以写在接口类上、接口方法上、实现类上和实现类方法上
- 写在接口类上,该接口的所有实现类的所有方法都会有事务
- 写在接口方法上,该接口的所有实现类的该方法都会有事务
- 写在实现类上,该类中的所有方法都会有事务
- 写在实现类方法上,该方法上有事务
- 建议写在实现类或实现类的方法上
步骤2:在JdbcConfig类中配置事务管理器
1 |
|
注意:事务管理器要根据使用技术进行选择,Mybatis框架使用的是JDBC事务,可以直接使用DataSourceTransactionManager
步骤3:开启事务注解
在springConfig的配置类中开启
1 |
|
步骤4:运行测试类
会发现在转换的业务出现错误后,事务就可以控制回顾,保证数据的正确性。
spring事务角色
要理解两个概念,分别是事务管理员
和事务协调员
。
未开启spring事务之前
- AccountDao的outMoney因为是修改操作,会开启一个事务T1
- AccountDao的inMoney因为是修改操作,会开启一个事务T2
- AccountService的transfer没有事务,
- 运行过程中如果没有抛出异常,则T1和T2都正常提交,数据正确
- 如果在两个方法中间抛出异常,T1因为执行成功提交事务,T2因为抛异常不会被执行
- 就会导致数据出现错误
开始spring的事务管理后
- transfer上添加了@Transactional注解,在该方法上就会有一个事务T
- AccountDao的outMoney方法的事务T1加入到transfer的事务T中
- AccountDao的inMoney方法的事务T2加入到transfer的事务T中
- 这样就保证他们在同一个事务中,当业务层中出现异常,整个事务就会回滚,保证数据的准确性
通过上面例子的分析,我们就可以得到如下概念:
- 事务管理员:发起事务方,在Spring中通常指代业务层开启事务的方法
- 事务协调员:加入事务方,在Spring中通常指代数据层方法,也可以是业务层方法
注意
目前的事务管理是基于DataSourceTransactionManager
和SqlSessionFactoryBean
使用的是同一个数据源。
Spring事务属性
- 事务配置
- 转账业务追加日志
- 事务传播行为
事务配置
上面这些属性都可以在@Transactional
注解的参数上进行设置。
readOnly:true只读事务,false读写事务,增删改要设为false,查询设为true。
timeout:设置超时时间单位秒,在多长时间之内事务没有提交成功就自动回滚,-1表示不设置超时时间。
rollbackFor:当出现指定异常进行事务回滚
noRollbackFor:当出现指定异常不进行事务回滚
思考:出现异常事务会自动回滚,这个是我们之前就已经知道的
noRollbackFor是设定对于指定的异常不回滚,这个好理解
rollbackFor是指定回滚异常,对于异常事务不应该都回滚么,为什么还要指定?
这块需要更正一个知识点,并不是所有的异常都会回滚事务,比如下面的代码就不会回滚
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27public interface AccountService {
/**
* 转账操作
* @param out 传出方
* @param in 转入方
* @param money 金额
*/
//配置当前接口方法具有事务
public void transfer(String out,String in ,Double money) throws IOException;
}
@Service
public class AccountServiceImpl implements AccountService {
@Autowired
private AccountDao accountDao;
@Transactional
public void transfer(String out,String in ,Double money) throws IOException{
accountDao.outMoney(out,money);
//int i = 1/0; //这个异常事务会回滚
if(true){
throw new IOException(); //这个异常事务就不会回滚
}
accountDao.inMoney(in,money);
}
}
出现这个问题的原因是,Spring的事务只会对
Error异常
和RuntimeException异常
及其子类进行事务回顾,其他的异常类型是不会回滚的,对应IOException不符合上述条件所以不回滚此时就可以使用rollbackFor属性来设置出现IOException异常不回滚
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16@Service
public class AccountServiceImpl implements AccountService {
@Autowired
private AccountDao accountDao;
@Transactional(rollbackFor = {IOException.class})
public void transfer(String out,String in ,Double money) throws IOException{
accountDao.outMoney(out,money);
//int i = 1/0; //这个异常事务会回滚
if(true){
throw new IOException(); //这个异常事务就不会回滚
}
accountDao.inMoney(in,money);
}
}
rollbackForClassName等同于rollbackFor,只不过属性为异常的类全名字符串
noRollbackForClassName等同于noRollbackFor,只不过属性为异常的类全名字符串
isolation设置事务的隔离级别
- DEFAULT :默认隔离级别, 会采用数据库的隔离级别
- READ_UNCOMMITTED : 读未提交
- READ_COMMITTED : 读已提交
- REPEATABLE_READ : 重复读取
- SERIALIZABLE: 串行化
转账业务追加日志
- 需求:实现任意两个账户间转账操作,并对每次转账操作在数据库进行留痕
- 需求微缩:A账户减钱,B账户加钱,数据库记录日志
基于上述的业务需求,我们来分析下该如何实现:
①:基于转账操作案例添加日志模块,实现数据库中记录日志
②:业务层转账操作(transfer),调用减钱、加钱与记录日志功能
这里只单独看日志这块功能。
步骤1:创建日志表
1 |
|
步骤2:添加LogDao接口
1 |
|
步骤3:添加LogService接口与实现类
1 |
|
步骤4:在转账的业务中添加记录日志
1 |
|
步骤5:运行程序
当程序正常运行,tbl_account表中转账成功,tbl_log表中日志记录成功
当转账业务之间出现异常(int i =1/0),转账失败,tbl_account成功回滚,但是tbl_log表未添加数据
这个结果和我们想要的不一样,什么原因?该如何解决?
失败原因:日志的记录与转账操作隶属同一个事务,同成功同失败
最终效果:无论转账操作是否成功,日志必须保留
事务传播行为
对于上述案例的分析:
- log方法、inMoney方法和outMoney方法都属于增删改,分别有事务T1,T2,T3
- transfer因为加了@Transactional注解,也开启了事务T
- 前面我们讲过Spring事务会把T1,T2,T3都加入到事务T中
- 所以当转账失败后,所有的事务都回滚,导致日志没有记录下来
- 这和我们的需求不符,这个时候我们就想能不能让log方法单独是一个事务呢?
要想解决这个问题,就需要用到事务传播行为,所谓的事务传播行为指的是:
事务传播行为:事务协调员对事务管理员所携带事务的处理态度。
具体如何解决,就需要用到之前我们没有说的propagation属性
。
修改logService改变事务的传播行为
1 |
|
运行后,就能实现我们想要的结果,不管转账是否成功,都会记录日志。
事务传播行为的可选值
对于我们开发实际中使用的话,因为默认值需要事务是常态的。根据开发过程选择其他的就可以了,例如案例中需要新事务就需要手工配置。其实入账和出账操作上也有事务,采用的就是默认值。