spring经典中文教程资料下载.pdf

spring经典中文教程资料下载.pdf

《spring经典中文教程资料下载.pdf》由会员分享，可在线阅读，更多相关《spring经典中文教程资料下载.pdf（88页珍藏版）》请在冰点文库上搜索。

笔者刚开始与印度同僚共事之时，每每组织项目会议，一屋子人频频摇头，让笔者倍感压力J）。

下班后，带着好友离职的失落，笔者夹着这本书走在回家的路上，恰巧路过东海岸，天色依然明朗，随意坐上了海边一家酒吧的露天吧台，要了杯啤酒，随手翻弄着书的扉页，不经意看见书中遍布的钢笔勾画的线条。

“呵呵，Paradeep这家伙，还真把这本书当回事啊”，一边笑着，一边摊开了此书，想看看到底是怎样的书让这样一个聪明老练的同事如此欣赏。

从此开始，这本书伴随笔者度过了整整一个月的业余时间.这本书，也就是出自RodJohnson的：

ExpertOne-on-OneJ2EEDesignandDevelopment此书已经由电子工业出版社出版，译版名为J2EE设计开发编程指南。

半年后，一个新的JavaFramework发布，同样出自RodJohnson的手笔，这自然引起了笔者极大的兴趣，这就是SpringFramework。

SpringFramework实际上是ExpertOne-on-OneJ2EEDesignandDevelopment一书中所阐述的设计思想的具体实现。

在One-on-One一书中，RodJohnson倡导J2EE实用主义的设计思想，并随书提供了一个初步的开发框架实现（interface21开发包）。

而SpringFramework正是这一思想的更全面和具体的体现。

RodJohnson在interface21开发包的基础之上，进行了进一步的改造和扩充，使其发展为一个更加开放、清晰、全面、高效的开发框架。

本文正是针对SpringFramework的开发指南，讲述了SpringFramework的设计思想以及在开发中的实际使用。

同时穿插了一些笔者在项目实作中的经验所得。

SpringFrameWorkDevelopersGuideVersion0.6September2,2004Somanyopensourceprojects.WhynotOpenyourDocuments?

Spring初探初探.5准备工作准备工作.5构建构建Spring基础代码基础代码.6Spring基础语义基础语义.12DependencyInjection.12依赖注入的几种实现类型依赖注入的几种实现类型.14Type1接口注入接口注入.15Type2构造子注入构造子注入.15Type3设值注入设值注入.15几种依赖注入模式的对比总结几种依赖注入模式的对比总结.16SpringBean封装机制.17BeanWrapper.17BeanFactory.18ApplicationContext.21WebContext.26Spring高级特性高级特性.27Web应用与MVC.27SpringMVC.28SpringMVC指南指南.28基于模板的Web表示层技术.42Web应用中模板技术与应用中模板技术与JSP技术的对比技术的对比.47输入验证与数据绑定输入验证与数据绑定.49异常处理异常处理.60国际化支持国际化支持.62数据持久层.66事务管理.66持久层封装.70JDBC.70HibernateinSpring.78ibatisinSpring.85以下内容待整理后发布.88远程调用.88AOP.88SpringFrameWorkDevelopersGuideVersion0.6September2,2004Somanyopensourceprojects.WhynotOpenyourDocuments?

Spring初探初探开始Spring研究之前，先让我们来看一个1分钟上手教程。

QuickStart!

准备工作准备工作下载SpringFramework的最新版本，并解压缩到指定目录。

在IDE中新建一个项目，并将Spring.jar将其相关类库加入项目。

笔者所用IDE为Eclipse，类库配置如下：

Spring采用Apachecommon_logging，并结合Apachelog4j作为日志输出组件。

为了在调试过程中能观察到Spring的日志输出，在CLASSPATH中新建log4j.properties配置文件，内容如下：

log4j.rootLogger=DEBUG,stdoutlog4j.appender.stdout=org.apache.log4j.ConsoleAppenderlog4j.appender.stdout.layout=org.apache.log4j.PatternLayoutlog4j.appender.stdout.layout.ConversionPattern=%c1-%m%n配置完成后，项目结构如下图所示：

构建构建Spring基础代码基础代码示例基础代码包括：

1Action接口:

Action接口定义了一个execute方法，在我们示例中，不同的Action实现提供了各自的execute方法，以完成目标逻辑。

publicinterfaceActionpublicStringexecute（Stringstr）;

2Action接口的两个实现UpperAction、LowerActionpublicclassUpperActionimplementsActionprivateStringmessage;

publicStringgetMessage（）returnmessage;

publicvoidsetMessage（Stringstring）message=string;

publicStringexecute（Stringstr）return（getMessage（）+str）.toUpperCase（）;

UpperAction将其message属性与输入字符串相连接，并返回其大写形式。

publicclassLowerActionimplementsActionprivateStringmessage;

publicStringexecute（Stringstr）return（getMessage（）+str）.toLowerCase（）;

LowerAction将其message属性与输入字符串相连接，并返回其小写形式。

3Spring配置文件（bean.xml）SpringQuickStartHeLLo（请确保配置bean.xml位于工作路径之下，注意工作路径并不等同于CLASSPATH，eclipse的默认工作路径为项目根路径，也就是.project文件所在的目录，而默认输出目录/bin是项目CLASSPATH的一部分，并非工作路径。

）4测试代码publicvoidtestQuickStart（）ApplicationContextctx=newFileSystemXmlApplicationContext（bean.xml）;

Actionaction=（Action）ctx.getBean（TheAction）;

System.out.println（action.execute（RodJohnson）;

可以看到，上面的测试代码中，我们根据bean.xml创建了一个ApplicationContext实例，并从此实例中获取我们所需的Action实现。

运行测试代码，我们看到控制台输出：

HELLORODJOHNSON我们将bean.xml中的配置稍加修改：

再次运行测试代码，看到：

hellorodjohnson示例完成！

很简单的示例，的确很简单，甚至简单到了不够真实。

不过，不知大家从这个最简单的例子中看出了什么？

真的只是打印输出了两行不痛不痒的问候语？

仔细观察一下上面的代码，可以看到：

1我们的所有程序代码中（除测试代码之外），并没有出现Spring中的任何组件。

2UpperAction和LowerAction的Message属性均由Spring通过读取配置文件（bean.xml）动态设置。

3客户代码（这里就是我们的测试代码）仅仅面向接口编程，而无需知道实现类的具体名称。

同时，我们可以很简单的通过修改配置文件来切换具体的底层实现类。

上面所说的这些，对于我们的实际开发有何帮助？

首先，我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚至不需要任何修改（这在基于EJB框架实现的应用中是难以想象的）。

其次，组件间的依赖关系减少，极大改善了代码的可重用性。

Spring的依赖注入机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合。

上面的例子中，我们通过Spring，在运行期动态将字符串“HeLLo”注入到Action实现类的Message属性中。

现在假设我们回到传统的实现模式，应该如何处理？

一般的处理办法也就是编写一个Helper类（辅助类），完成配置文件读写功能，然后在各个Action的构造函数中，调用这个Helper类设置message属性值。

此时，我们的组件就与这个Helper类库建立了依赖关系，之后我们需要在其他系统中重用这个组件的话，也必须连同这个Helper类库一并移植。

实际开发中，依赖关系往往并非如此简单，组件与项目基层代码之间复杂的关联，使得组件重用性大大下降。

Spring通过依赖注入模式，将依赖关系从编码中脱离出来，从而大大降低了组件之间的耦合，实现了组件真正意义上的即插即用。

这也是Spring最具价值的特性之一。

面向接口编程。

诚然，即使没有Spring，实现面向接口的设计也不困难。

Spring对于面向接口设计的意义，在于它为面向接口编程提供了一个更加自然的平台。

基于Spring开发，程序员会自然而然倾向于使用接口来定义不同层次之间的关联关系，这种自发的倾向性，来自于Spring所提供的简单舒适的依赖注入实现。

Spring使得接口的定义和使用不再像传统编码过程中那么繁琐（传统编码过程中，引入一个接口，往往也意味着同时要引入一个Factory类，也许还有一个额外的配置文件及其读写代码）。

既然Spring给我们带来了如此这般的好处，那么，反过来，让我们试想一下，如果不使用Spring框架，回到我们传统的编码模式（也许正是目前的编码模式），情况会是怎样？

对于上例而言，我们需要怎样才能实现相同的功能？

上面的Action接口及其两个实现类UpperAction和LowerAction都与Spring无关，可以保留。

而调用Action的测试代码，如果要实现同样的功能，应该如何编写？

首先，我们必须编写一个配置文件读取类，以实现Message属性的可配置化。

其次，得有一个Factory模式的实现，并结合配置文件的读写完成Action的动态加载。

于是，我们实现了一个ActionFactory来实现这个功能：

publicclassActionFactorypublicstaticActiongetAction（StringactionName）Propertiespro=newProperties（）;

trypro.load（newFileInputStream（config.properties）;

StringactionImplName=（String）pro.get（actionName）;

StringactionMessage=（String）pro.get（actionName+_msg）;

Objectobj=Class.forName（actionImplName）.newInstance（）;

/BeanUtils是ApacheCommonsBeanUtils提供的辅助类BeanUtils.setProperty（obj,message,actionMessage）;

return（Action）obj;

catch（FileNotFoundExceptione）e.printStackTrace（）;

catch（IOExceptione）e.printStackTrace（）;

catch（ClassNotFoundExceptione）e.printStackTrace（）;

catch（InstantiationExceptione）e.printStackTrace（）;

catch（IllegalAccessExceptione）e.printStackTrace（）;

catch（InvocationTargetExceptione）e.printStackTrace（）;

returnnull;

配置文件则采用最简单的properties文件形式：

TheAction=net.xiaxin.spring.qs.UpperActionTheAction_msg=HeLLo测试代码对应更改为：

publicvoidtestFactory（）Actionaction=ActionFactory.getAction（TheAction）;

且不论实现质量的好坏，总之通过上面新增的20来行代码，我们实现了类似的功能（如果不引入BeanUtils，而采用手工编写Reflection代码完成属性设置的话，显然代码将远远不止20行）。

好吧，现在有个新需求，这个ActionFactory每次都新建一个类的实例，这对系统性能不利，考虑到我们的两个Action都是线程安全的，修改一下ActionFactory，保持系统中只有一个Action实例供其他线程调用。

另外Action对象创建后，需要做一些初始化工作。

修改一下ActionFactory，使其在创建Action实例之后，随即就调用Action.init方法执行初始化。

嗯，好像每次创建Action对象的时就做初始化工作消耗了很多无谓资源，来个LazyLoading吧，只有Action实例被实际调用的时候再做初始化。

差不多了，Action的处理就这样吧。

下面我们来看看另外一个Factory。

往往这些系统开发中最常见的需求，会导致我们的代码迅速膨胀。

纵使苦心经营，往往也未必能得全功。

而Spring的出现，则大大缓解了这样的窘境。

通过对编码中常见问题的分解和抽象，Spring提供了一套成熟而全面的基础框架。

随着本篇的进展，大家可以看到，上面这些开发中常见的问题在Spring框架中都提供了统一、妥善的处理机制，这为烦杂的应用开发提供了相当有力的支持。

这里暂且抛开SpringFramework在设计上相当出彩的表现不谈。

站在应用开发的实际角度来说，其最大的优势在于：

Spring是一个从实际项目开发经验中抽取的，可高度重用的应用框架是一个从实际项目开发经验中抽取的，可高度重用的应用框架。

认识到这一点非常重要。

SpringFramework中目前最引人注目的，也就是名为控制反转（IOCInverseOfControl）或者依赖注入（DIDependenceInjection）的设计思想，这的确是相当优秀的设计理念，但是，光一个单纯的设计模式并不能使得Spring如此成功，而Spring最成功的地方也并不仅仅在于采用了IOC/DI的设计。

我们前面示例中的ActionFactory，勉强也可算做是一个IOC/DI设计的实现，但又如何？

可能相关技术媒体和不明就里的技术追随者对于DI/IOC容器的过分炒作，在某种程度上误导了初学者的视线。

“控制反转”，这显然不是一个能望文知意的好名称；

“依赖注入”，也好不到哪里去，也正因为这样，不少初学者都将Spring和生涩的所谓“控制反转”和“依赖注入”看作一个懵懂的高级概念而供上了神龛。

而实际上，Spring是笔者所见过的，最具实际意义的Java开发框架。

它绝非一个高级概念玩具，而是一个切实的，能实实在在帮助我们改善系统设计的好帮手。

首先，Spring涵盖了应用系统开发所涉及的大多数技术范畴，包括MVC、ORM以及RemoteInterface等，这些技术往往贯穿了大多数应用系统的开发过程。

Spring从开发者的角度对这些技术内容进行了进一步的封装和抽象，使得应用开发更为简便。

在笔者的开发工作中，借助Spring提供的丰富类库，相对传统开发模式，大大节省了编码量（平均1/3强，对于ORM和Remote层也许更多）。

其次，Spring并非一个强制性框架，它提供了很多独立的组件可供选择。

如笔者在一些项目中，就仅引用了Spring的ORM模板机制对数据存取层进行处理，并取得了相当理想的效果。

评定一个框架是否优良的条件固然有很多种，但是笔者始终认为，对于应用系统开发而言，我们面临着来自诸多方面的压力，此时，最能提高生产力的技术，也就是最有价值的技术。

很高兴，Spring让笔者找到了这样的感觉。

笔者对RodJohnson最为钦佩的，并不是他用了IOC或者DI，而是他对J2EE应用开发的透彻的理解。

他真的明白开发人员需要什么。

Spring基础语义基础语义DependencyInjection何谓控制反转（IoC=InversionofControl），何谓依赖注入（DI=DependencyInjection）？

对于初次接触这些概念的初学者，不免会一头雾水。

正如笔者第一次看到这些名词一样，一阵窘迫IT界不亏是哄抢眼球的行业，每个新出现的语汇都如此迷离。

好在我们也同时拥有Internet这个最广博的信息来源。

IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。

这也就是所谓“控制反转”的概念所在：

控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。

正在业界为IoC争吵不休时，大师级人物MartinFowler也站出来发话，以一篇经典文章InversionofControlContainersandtheDependencyInjectionpattern为IoC正名，至此，IoC又获得了一个新的名字：

“依赖注入（DependencyInjection）”。

相对IoC而言，“依赖注入”的确更加准确的描述了这种古老而又时兴的设计理念。

从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。

为什么称之为“古老而又时兴”的设计理念？

至于“时兴”自然不必多费唇舌，看看国内外大小论坛上当红的讨论主题便知。

至于“古老”，相信大家对下面图片中的设备不会陌生：

这就是笔者的主要工作装备，IBMT40笔记本电脑一台、USB硬盘和U盘各一只。

想必大家在日常工作中也有类似的一套行头。

这与依赖注入有什么关系？

图中三个设备都有一个共同点，都支持USB接口。

当我们需要将数据复制到外围存储设备时，可以根据情况，选择是保存在U盘还是USB硬盘，下面的操作大家也都轻车熟路，无非接通USB接口，然后在资源浏览器中将选定的文件拖放到指定的盘符。

这样的操作在过去几年中每天都在我们身边发生，而这也正是所谓依赖注入的一个典型案例，上面称SpringFrameWorkDevelopersGuideVersion0.6September2,2004Somanyopensourceprojects.WhynotOpenyourDocuments?

之为“古老”想必也不为过分。

再看上例中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记