Spring系统架构与主要概念
- Spring Framework系统架构
- Core Container 核心容器
- AOP 层
- 数据层
- Web层
- 测试层
- 业务逻辑
- Spring之前遇到的问题
- 解决方案
- Spring核心概念
- IOC(Inversion of Control)控制反转
- DI(Dependency Injection)依赖注入
Spring Framework系统架构
Spring 更新至Spring5.0,不过我们依旧以Spring4.0系统架构图作为基础观察:
Core Container 核心容器
- Core Container:核心容器,这个模块是Spring最核心的模块,其他的都需要依赖该模块
AOP 层
- AOP:面向切面编程,它依赖核心层容器,目的是在不改变原有代码的前提下对其进行功能增强。
- Aspects:AOP是思想,Aspects是对AOP思想的具体实现。
数据层
- Data Access:数据访问,Spring全家桶中有对数据访问的具体实现技术。
- Data Integration:数据集成,Spring支持整合其他的数据层解决方案,比如Mybatis。
- Transactions:事务,Spring中事务管理是Spring AOP的一个具体实现。
Web层
测试层
业务逻辑
Spring之前遇到的问题
在Spring之前我们写代码容易遇到高耦合问题,如下图所示,业务层的实现需要new一个数据层的对像,但是如果我们的数据层发生改变时,业务层的对象必须重新新建,重新进行编译、打包、部署,改动相对较多,代码耦合度较高。
解决方案
很明显如果我们可以把业务层的对象健在别的地方就能避免这种情况。
当然直接去掉是肯定不行的,我们之前说了只是健在别的地方,Spring便是帮我们做这个事情
Spring核心概念
IOC(Inversion of Control)控制反转
使用对象时,由主动new产生对象转换为由外部提供对象,此过程中对象创建控制权由程序转移到外部,此思想称为控制反转。
也就是说,我们把需要新建的对象(当然不止我们之前提到的数据层对象,业务层对象同样也可以)放在IOC容器中(交给IOC管理),每当我们需要对象时,直接找IOC拿就行,而在IOC容器中这些被创建管理的对象,我们把它叫做Bean
所以我们把所有对象放在IOC就可以直接启动该程序了吗?嗯?可是我们怎么知道业务层和数据层的关系捏?我们开发的逻辑当然是Service业务层依赖Dao层的数据,现在IOC中只是又了对象,可他们之间我们并没有赋予关系,所以当然是启动不了啦,所以我们需要把dao层对象交给service,也就是说要绑定service和dao对象之间的关系,于是我们引入新的概念 DI(Dependency Injection)依赖注入。
DI(Dependency Injection)依赖注入
如图所示,DI依赖注入就是建立IOC容器中各个对象之间的关系。