第10章 Spring框架
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
JavaEE企业级应用开发 （基础应用）
第10章
Spring 框架
*
Spring是什么
• 轻量级框架 – 发布仅单一jar包 AOP(Aspect-oriented programming) – 额外的消耗可忽略不计 面向方面编程 – 非侵入性 OOP及IoC的补充 容器 通用解决方案及最佳实践 – 管理对象的生命周期 当前流行开源产品的封装 – 控制对象的创建方式 Ioc/DI(Inversion of Control/ Dependency Injection) – 控制反转/依赖注入 – 配置及管理对象的依赖关系
IoC
IoC的直译是控制反转。 在IoC模式下，控制权限从应用程序转移到了IoC容器中。组件不是由应 用程序负责创建和配置，而是由IoC容器负责。 使用IoC的情况下，对象是被动地接收依赖类而不是主动地查找。对象 不是从容器中查找他的依赖类，而是容器在实例化对象时，主动地将他 所依赖的对象注入给他。 应用程序只需要直接使用已经创建并且配置好的组件即可，而不必自己 负责创建和配置。 在实际的工作中人们发现使用IoC来表述这种机制，并不是很准确甚至 有些晦涩，于是引发了另外一个概念：DI(依赖注入)
MVC 框架是一个全功能的构建 Web 应用程序 的 MVC 实现。 通过策略接口，MVC 框架变成为高度可配置的 。MVC 容纳了大量视图技术，其中包括 Jsp、 Velocity、Tiles、iText 和 POI等。
为什么使用Spring
没有使用Spring： 充斥了很多工厂类、singleton单例模式； 配置也不够集中，没有一个统一的管理； 在业务层，我们一般都需要依赖Dao，我们需要自己写一些工厂类来 生成；
简单的约定
• 我们在讲课时一律采用“依赖注入”这个 概念，而提到容器时，我们采用“IoC容器 ”一词，因为他更加流行。
控制反转/依赖注入
好莱坞原则 Don’t Call me（指Ioc容器）, I will call you（被调用的组件）.
为何使用IoC
• • • • • • • • • 有效地组织中间层对象 有效的消除单例、工厂等模式的使用 将面向接口编程做到实处 使单元测试变得简单 消除了依赖环境的查找和特定服务器的代码 代码变得清晰，易于维护和扩展 代码依赖于接口，易于复用 便于看清组件之间的依赖关系 便于团队分模块开发
•
•
Spring是一个开源的JavaEE框架。它作为一个优秀的轻量级的企业应 用开发框架，可以大大简化企业应用开发的复杂性，能够创建出松耦合 、易测试、易扩展、易维护的Java应用系统。就象春风一样，吹拂着 Java大地。
*
初识Spring
• Spring提供了一种轻量级的解决方案，用于建立“快装式企业应用” 。在此基础上，Spring还提供了包括声明式事务管理，RMI或Web Services远程访问业务逻辑，以及可以多种方法进行的持久化数据库 地解决方案。另外，Spring还有一个全功能的 MVC框架，并能透明的 把 AOP 集成到你的软件中去。 • 你可以把Spring当作一个潜在的一站式企业应用。或者，把Spring看 作一个标准开发组件，根据自己的需要，只取用它的部分组件使用而 无需涉及其他。例如，你可以利用控制反转容器在前台的展现层使用 Struts，还可以只使用 Hibernate集成编码 或是 JDBC抽象层去处理 数据存储。 • Spring被设计成（并将继续保持）无侵入性的方式，意味着应用几乎 不需要对框架进行依赖（或根据实际使用的范围，将依赖做到最小） 。
2
3
对象创建方式
原始社会 UserBusines business=new UserBusiness(); 封建社会 程序世界进入半现代社会，我们应用工厂进行解耦，虽然使用者不 再new一个对象了，可是，也不过仅仅是把对象的创建过程封 装到了工厂中而已，我们毕竟还是new了一个对象。耦合并没 有完全解除。
解析IoC和DI(下)
DI解析 之所以会产生组件调用，是为了获取被调用组件的功能，调用者将自 己应该做的事情，委派给了被调用的对象。也就是说，调用者要完成 自身的任务，必须依赖被调用的对象。这种关系实际上就是一般依赖 关系(通俗点说，就是一个组件内部包含另外一个组件的实例，把该 自己干的事交给自己包含的组件去完成)。因此IoC所表述的机制，实 际上就是将调用者对接口实现类的依赖关系，从程序中移除，转交第 三方管理实例。并且，由第三方在运行期间将调用者依赖的具体类填 充进来。也就是说组件之间的依赖关系，是在程序运行期间由第三方 来管理的。这个就是依赖注入的概念(DI)，基于上述分析，DI比IoC 更准确。 实际上就是将调用者为完成功能所依赖的实现类，在程序运行期间， 由容器自动填充给调用者，这个就是依赖注入的核心思想。在依赖注 入的应用中，组件并不关心被注入的对象是谁，只关系这个对象能完 成的功能，也就是这个对象是哪个接口的具体类实例。
使用Spring 它是轻量级的，没有侵入性，这是它流行的主要原因。 我们来装配对象的依赖关系 把各个对象之间的依赖关系交给Spring 的IoC容器来做。
为什么使用Spring（续）
通过示例可见这个组装过程是由我们来做的，而且我们已经把这个写死了， 对象是我们new出来的。在程序里，这样的对象很多，对于一个大型的项目 ，不能这样都写死了！而且这样装配会很复杂，如果Dao还依赖别的东西的 话，还要继续装配。 Spring的IoC就可以帮助我们进行组装。什么是控制反转：把组装交给别人 了来做；像之前的这种关系，是由我们自己来维护的；反转后，这些工作由 IOC容器来做。它提供了这种相应配置，我们把这种依赖关系配置上就可以 了。比如：UserManager依赖于UserDao4Oracle，所有这些我们都配置好 ，那么Spring会自动的把UserDao4Oracle实例化好，将UserManager实例 化好，然后调用UserManager构造，自动的把实例化好的UserDao4Oracle 的这个实现给你放进去。 但是这个放进去是有前提的，就是说这个UserManager要提供一个构造函 数，或是这个类要提供一个Set方法，将这个UserDao set 进去。这个过程 我们称之为“注入”。
*
传统组件调用方式
缺陷分析
1 无法真正动态加载 无法动态替换。替换时必须修改代码，即使应用的是工厂，依然存在代 码修改的情况，因为我们必须重新设计工厂。 实例无法共享 多组件无法共享同一实例。因为实例的生命周期是依赖于调用者组件， 二者同生共死，即使应用工厂，也是每个实例只为一个客户端使用。 测试困难 因为必须包含一个组件的实例，如果实例包含了数据库引用的话，无法 离开数据库运行环境。
Spring框架组成（四）
Spring DAO：
这个模块封装了数据库连接的创建、语句对象 生成、结果集处理、连接关闭等操作，而且重 构了所有数据库系统的异常信息，用户不再需 要处理数据库异常了。
在这个模块中，利用了Spring的AOP模块完成 了为系统中对象提供事务管理的服务。
Spring框架组成（五）
依赖注入
目前人们认为使用依赖注入（DI—— Dependency Injection ）来阐述 IoC更为合适。 而事实上早在2004年初，Martin Fowler在他的站点谈论控制反转时曾提 问： “问题在于，它们转变的是什么方面的控制？”。 Fowler建议重命 名该原则（或至少给它一个更加明确的名称），并开始使用“依赖注入” 这个术语。
开发人员面临的窘境
• • • • • 代码侵入性、依赖性较强 单元测试极其困难 代码混乱，维护性和扩展性差 代码难以复用 不利于分工，降低开发效率
• 解决之道就是应用IoC – 让组件之间的依赖关系通过抽象(接口或抽象类的变量)来建立。 在组件运行期间，将组件依赖的实际对象注入(填充)进来，并由 组件内部包含的抽象变量来引用。从而，就可以解藕了。
Spring ORM：
Spring 没有实现自己的ORM方案，而是为当 前主流的ORM框架预留了整合接口，包括 hibernate、JDO等。 所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。 Spring的事物管理支持所有这些ORM框架以 及JDBC。
Spring框架组成（六）
Spring Web 模块：
Web 上下文模块建立在应用程序上下文模块之上 ，为基于 Web 的应用程序提供了上下文。 Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定 到域对象的工作。
Βιβλιοθήκη Baidu Spring框架组成（七）
Spring MVC 框架：
解析IoC和DI(上)
IoC解析 IoC(控制反转)是Spring容器的内核，AOP以及声明式事务都是在此之 上完成的。IoC包括两层含义：1.控制，2反转。关键的问题在于他把 什么东西的控制给反转了。 控制指组件之间的调用关系由程序自身控制(从而造成了紧耦合)。 反转是说，将这种调用关系的控制权从程序中移除，并交给第三方管 理。 也就是组件的调用关系由程序自身管理转变为第三方管理，是组件依赖关 系的控制权进行了反转。 对于上述机制，应用IoC来描述并不准确，而且有些晦涩。
Spring框架组成（三）
Spring AOP： AOP面向切面编程。该模块将AOP 编程功能集成到了 Spring 框 架中。这样，凡是 Spring 框架管理的任何对象都可以很容易地 支持 AOP。该模块为应用程序中基于 Spring 管理的对象提供了 事务管理服务。 这个模块由于使用了 AOP Alliance的API，所以，可以和其他 AOP框架互通， AOP Alliance是一个开源项目，目的是促进AOP的使用，并且通 过定义一套通用的接口和组件来确保不同的AOP之间达到互通性 。
目标
• 使JavaEE更简单易用，促进良好的编程习 惯 • 使已经存在的技术更简单易用 • 集成已存在的成熟应用解决方案，遵守不 重新发明轮子的原则 • 不用EJB来开发JavaEE应用程序 • 提供最好的IOC解决方案 • 提供最好的AOP解决方案
*
优点
• • • • • • • • • • • • 开源框架，开放性较高 有效地组织中间层对象 多种可选的事务处理方式 多种可选的持久层策略 多种可选的Web MVC框架策略 高度可扩展的安全解决方案 有效的消除单例、工厂等模式的使用 将面向接口编程做到实处 使单元测试变得简单 使EJB的使用成为一个选择 提供了一致的数据访问框架 只选择你需要的
Spring框架组成（二）
Application Context（上下文） 由一个配置文件，向 Spring 框架提供上下文信息。
BeanFactory使spring成为容器，上下文模块使Spring成为框架 。 这个模块对BeanFactory进行了扩展，添加了对I18N，系统生命 周期事件以及验证的支持。 这个模块提供了许多企业级服务，例 如：邮件服务，JNDI访问，EJB集成，远程调用以及定时服务， 并且支持与模板框架的集成。
*
框架组成
*
Spring框架组成（一）
核心容器： 核心容器提供Spring框架的基本功能,为Spring提供了基础服务 支持，核心容器的主要组件就是BeanFactory BeanFactory是所有基于Spring框架系统的核心，通过 BeanFactory，Spring使用工厂模式来实现IoC，将应用程序的 配置和依赖关系与实际的应用程序分离开来。 Spring之所以称为容器，就是由于BeanFactory的自动装备和注 入。
*
Spring的历史及目标
• Spring的核心代码均来自于真实的项目，Rod Johnson是这个产品的 创造者，是从商业项目开发实践中逐步提炼出的一种架构基调。 • 从2003年正式启动，整个项目的开发始终贯彻着如下的核心架构理念 ，具有概念上的完整性和一致性： – 降低开发成本 – 方便使用 – 整合各类框架 – 易于选择 – 方便测试 – 统一配置 – 灵活可扩展 – 非侵入性
第10章
Spring 框架
*
Spring是什么
• 轻量级框架 – 发布仅单一jar包 AOP(Aspect-oriented programming) – 额外的消耗可忽略不计 面向方面编程 – 非侵入性 OOP及IoC的补充 容器 通用解决方案及最佳实践 – 管理对象的生命周期 当前流行开源产品的封装 – 控制对象的创建方式 Ioc/DI(Inversion of Control/ Dependency Injection) – 控制反转/依赖注入 – 配置及管理对象的依赖关系
IoC
IoC的直译是控制反转。 在IoC模式下，控制权限从应用程序转移到了IoC容器中。组件不是由应 用程序负责创建和配置，而是由IoC容器负责。 使用IoC的情况下，对象是被动地接收依赖类而不是主动地查找。对象 不是从容器中查找他的依赖类，而是容器在实例化对象时，主动地将他 所依赖的对象注入给他。 应用程序只需要直接使用已经创建并且配置好的组件即可，而不必自己 负责创建和配置。 在实际的工作中人们发现使用IoC来表述这种机制，并不是很准确甚至 有些晦涩，于是引发了另外一个概念：DI(依赖注入)
MVC 框架是一个全功能的构建 Web 应用程序 的 MVC 实现。 通过策略接口，MVC 框架变成为高度可配置的 。MVC 容纳了大量视图技术，其中包括 Jsp、 Velocity、Tiles、iText 和 POI等。
为什么使用Spring
没有使用Spring： 充斥了很多工厂类、singleton单例模式； 配置也不够集中，没有一个统一的管理； 在业务层，我们一般都需要依赖Dao，我们需要自己写一些工厂类来 生成；
简单的约定
• 我们在讲课时一律采用“依赖注入”这个 概念，而提到容器时，我们采用“IoC容器 ”一词，因为他更加流行。
控制反转/依赖注入
好莱坞原则 Don’t Call me（指Ioc容器）, I will call you（被调用的组件）.
为何使用IoC
• • • • • • • • • 有效地组织中间层对象 有效的消除单例、工厂等模式的使用 将面向接口编程做到实处 使单元测试变得简单 消除了依赖环境的查找和特定服务器的代码 代码变得清晰，易于维护和扩展 代码依赖于接口，易于复用 便于看清组件之间的依赖关系 便于团队分模块开发
•
•
Spring是一个开源的JavaEE框架。它作为一个优秀的轻量级的企业应 用开发框架，可以大大简化企业应用开发的复杂性，能够创建出松耦合 、易测试、易扩展、易维护的Java应用系统。就象春风一样，吹拂着 Java大地。
*
初识Spring
• Spring提供了一种轻量级的解决方案，用于建立“快装式企业应用” 。在此基础上，Spring还提供了包括声明式事务管理，RMI或Web Services远程访问业务逻辑，以及可以多种方法进行的持久化数据库 地解决方案。另外，Spring还有一个全功能的 MVC框架，并能透明的 把 AOP 集成到你的软件中去。 • 你可以把Spring当作一个潜在的一站式企业应用。或者，把Spring看 作一个标准开发组件，根据自己的需要，只取用它的部分组件使用而 无需涉及其他。例如，你可以利用控制反转容器在前台的展现层使用 Struts，还可以只使用 Hibernate集成编码 或是 JDBC抽象层去处理 数据存储。 • Spring被设计成（并将继续保持）无侵入性的方式，意味着应用几乎 不需要对框架进行依赖（或根据实际使用的范围，将依赖做到最小） 。
2
3
对象创建方式
原始社会 UserBusines business=new UserBusiness(); 封建社会 程序世界进入半现代社会，我们应用工厂进行解耦，虽然使用者不 再new一个对象了，可是，也不过仅仅是把对象的创建过程封 装到了工厂中而已，我们毕竟还是new了一个对象。耦合并没 有完全解除。
解析IoC和DI(下)
DI解析 之所以会产生组件调用，是为了获取被调用组件的功能，调用者将自 己应该做的事情，委派给了被调用的对象。也就是说，调用者要完成 自身的任务，必须依赖被调用的对象。这种关系实际上就是一般依赖 关系(通俗点说，就是一个组件内部包含另外一个组件的实例，把该 自己干的事交给自己包含的组件去完成)。因此IoC所表述的机制，实 际上就是将调用者对接口实现类的依赖关系，从程序中移除，转交第 三方管理实例。并且，由第三方在运行期间将调用者依赖的具体类填 充进来。也就是说组件之间的依赖关系，是在程序运行期间由第三方 来管理的。这个就是依赖注入的概念(DI)，基于上述分析，DI比IoC 更准确。 实际上就是将调用者为完成功能所依赖的实现类，在程序运行期间， 由容器自动填充给调用者，这个就是依赖注入的核心思想。在依赖注 入的应用中，组件并不关心被注入的对象是谁，只关系这个对象能完 成的功能，也就是这个对象是哪个接口的具体类实例。
使用Spring 它是轻量级的，没有侵入性，这是它流行的主要原因。 我们来装配对象的依赖关系 把各个对象之间的依赖关系交给Spring 的IoC容器来做。
为什么使用Spring（续）
通过示例可见这个组装过程是由我们来做的，而且我们已经把这个写死了， 对象是我们new出来的。在程序里，这样的对象很多，对于一个大型的项目 ，不能这样都写死了！而且这样装配会很复杂，如果Dao还依赖别的东西的 话，还要继续装配。 Spring的IoC就可以帮助我们进行组装。什么是控制反转：把组装交给别人 了来做；像之前的这种关系，是由我们自己来维护的；反转后，这些工作由 IOC容器来做。它提供了这种相应配置，我们把这种依赖关系配置上就可以 了。比如：UserManager依赖于UserDao4Oracle，所有这些我们都配置好 ，那么Spring会自动的把UserDao4Oracle实例化好，将UserManager实例 化好，然后调用UserManager构造，自动的把实例化好的UserDao4Oracle 的这个实现给你放进去。 但是这个放进去是有前提的，就是说这个UserManager要提供一个构造函 数，或是这个类要提供一个Set方法，将这个UserDao set 进去。这个过程 我们称之为“注入”。
*
传统组件调用方式
缺陷分析
1 无法真正动态加载 无法动态替换。替换时必须修改代码，即使应用的是工厂，依然存在代 码修改的情况，因为我们必须重新设计工厂。 实例无法共享 多组件无法共享同一实例。因为实例的生命周期是依赖于调用者组件， 二者同生共死，即使应用工厂，也是每个实例只为一个客户端使用。 测试困难 因为必须包含一个组件的实例，如果实例包含了数据库引用的话，无法 离开数据库运行环境。
Spring框架组成（四）
Spring DAO：
这个模块封装了数据库连接的创建、语句对象 生成、结果集处理、连接关闭等操作，而且重 构了所有数据库系统的异常信息，用户不再需 要处理数据库异常了。
在这个模块中，利用了Spring的AOP模块完成 了为系统中对象提供事务管理的服务。
Spring框架组成（五）
依赖注入
目前人们认为使用依赖注入（DI—— Dependency Injection ）来阐述 IoC更为合适。 而事实上早在2004年初，Martin Fowler在他的站点谈论控制反转时曾提 问： “问题在于，它们转变的是什么方面的控制？”。 Fowler建议重命 名该原则（或至少给它一个更加明确的名称），并开始使用“依赖注入” 这个术语。
开发人员面临的窘境
• • • • • 代码侵入性、依赖性较强 单元测试极其困难 代码混乱，维护性和扩展性差 代码难以复用 不利于分工，降低开发效率
• 解决之道就是应用IoC – 让组件之间的依赖关系通过抽象(接口或抽象类的变量)来建立。 在组件运行期间，将组件依赖的实际对象注入(填充)进来，并由 组件内部包含的抽象变量来引用。从而，就可以解藕了。
Spring ORM：
Spring 没有实现自己的ORM方案，而是为当 前主流的ORM框架预留了整合接口，包括 hibernate、JDO等。 所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。 Spring的事物管理支持所有这些ORM框架以 及JDBC。
Spring框架组成（六）
Spring Web 模块：
Web 上下文模块建立在应用程序上下文模块之上 ，为基于 Web 的应用程序提供了上下文。 Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定 到域对象的工作。
Βιβλιοθήκη Baidu Spring框架组成（七）
Spring MVC 框架：
解析IoC和DI(上)
IoC解析 IoC(控制反转)是Spring容器的内核，AOP以及声明式事务都是在此之 上完成的。IoC包括两层含义：1.控制，2反转。关键的问题在于他把 什么东西的控制给反转了。 控制指组件之间的调用关系由程序自身控制(从而造成了紧耦合)。 反转是说，将这种调用关系的控制权从程序中移除，并交给第三方管 理。 也就是组件的调用关系由程序自身管理转变为第三方管理，是组件依赖关 系的控制权进行了反转。 对于上述机制，应用IoC来描述并不准确，而且有些晦涩。
Spring框架组成（三）
Spring AOP： AOP面向切面编程。该模块将AOP 编程功能集成到了 Spring 框 架中。这样，凡是 Spring 框架管理的任何对象都可以很容易地 支持 AOP。该模块为应用程序中基于 Spring 管理的对象提供了 事务管理服务。 这个模块由于使用了 AOP Alliance的API，所以，可以和其他 AOP框架互通， AOP Alliance是一个开源项目，目的是促进AOP的使用，并且通 过定义一套通用的接口和组件来确保不同的AOP之间达到互通性 。
目标
• 使JavaEE更简单易用，促进良好的编程习 惯 • 使已经存在的技术更简单易用 • 集成已存在的成熟应用解决方案，遵守不 重新发明轮子的原则 • 不用EJB来开发JavaEE应用程序 • 提供最好的IOC解决方案 • 提供最好的AOP解决方案
*
优点
• • • • • • • • • • • • 开源框架，开放性较高 有效地组织中间层对象 多种可选的事务处理方式 多种可选的持久层策略 多种可选的Web MVC框架策略 高度可扩展的安全解决方案 有效的消除单例、工厂等模式的使用 将面向接口编程做到实处 使单元测试变得简单 使EJB的使用成为一个选择 提供了一致的数据访问框架 只选择你需要的
Spring框架组成（二）
Application Context（上下文） 由一个配置文件，向 Spring 框架提供上下文信息。
BeanFactory使spring成为容器，上下文模块使Spring成为框架 。 这个模块对BeanFactory进行了扩展，添加了对I18N，系统生命 周期事件以及验证的支持。 这个模块提供了许多企业级服务，例 如：邮件服务，JNDI访问，EJB集成，远程调用以及定时服务， 并且支持与模板框架的集成。
*
框架组成
*
Spring框架组成（一）
核心容器： 核心容器提供Spring框架的基本功能,为Spring提供了基础服务 支持，核心容器的主要组件就是BeanFactory BeanFactory是所有基于Spring框架系统的核心，通过 BeanFactory，Spring使用工厂模式来实现IoC，将应用程序的 配置和依赖关系与实际的应用程序分离开来。 Spring之所以称为容器，就是由于BeanFactory的自动装备和注 入。
*
Spring的历史及目标
• Spring的核心代码均来自于真实的项目，Rod Johnson是这个产品的 创造者，是从商业项目开发实践中逐步提炼出的一种架构基调。 • 从2003年正式启动，整个项目的开发始终贯彻着如下的核心架构理念 ，具有概念上的完整性和一致性： – 降低开发成本 – 方便使用 – 整合各类框架 – 易于选择 – 方便测试 – 统一配置 – 灵活可扩展 – 非侵入性