Spring 入门教程

Spring入门教程Spring入门教程2010-10-0720:32Spring入门教程1．Spring简介（1）Spring是什么Spring是轻量级的J2EE应用程序开源框架。它由RodJohnson创建。它是为了解决企业应用开发的复杂性而创建的。Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。Spring的核心是个轻量级容器（container），实现了IoC（InversionofControl）模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代，Spring希望提供one-stopshop的框架整合方案Spring不会特别去提出一些子框架来与现有的OpenSource框架竞争，除非它觉得所提出的框架够新够好，例如Spring有自己的MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但它不强迫您使用它提供的方案，您可以选用您所希望的框架来取代其子框架，例如您仍可以在Spring中整合您的Struts框架。Spring的核心概念是IoC，IoC的抽象概念是「依赖关系的转移」，像是「高层模块不应该依赖低层模块，而是模块都必须依赖于抽象」是IoC的一种表现，「实现必须依赖抽象，而不是抽象依赖实现」也是IoC的一种表现，「应用程序不应依赖于容器，而是容器服务于应用程序」也是IoC的一种表现。回想一下面向对象的设计原则：OCP原则和DIP原则。Spring的核心即是个IoC/DI的容器，它可以帮程序设计人员完成组件（类别们）之间的依赖关系注入（连结），使得组件（类别们）之间的依赖达到最小，进而提高组件的重用性，Spring是个低侵入性（invasive）的框架，Spring中的组件并不会意识到它正置身于Spring中，这使得组件可以轻易的从框架中脱离，而几乎不用任何的修改，反过来说，组件也可以简单的方式加入至框架中，使得组件甚至框架的整合变得容易。Spring最为人重视的另一方面是支持AOP（Aspect-OrientedProgramming），然而AOP框架只是Spring支持的一个子框架，说Spring框架是AOP框架并不是一件适当的描述，人们对于新奇的AOP关注映射至Spring上，使得人们对于Spring的关注集中在它的AOP框架上，虽然有所误解，但也突显了Spring的另一个令人关注的特色。Spring也提供MVCWeb框架的解决方案，但您也可以将自己所熟悉的MVCWeb框架与Spring解合，像是Struts、Webwork等等，都可以与Spring整合而成为适用于自己的解决方案。Spring也提供其它方面的整合，像是持久层的整合如JDBC、O/RMapping工具（Hibernate、iBATIS）、事务处理等等，Spring作了对多方面整合的努力，故说Spring是个全方位的应用程序框架。Spring框架由七个定义明确的模块组成：图1Spring框架概览图总的来说，Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架。轻量??从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于Spring的特定类。控制反转??Spring通过一种称作控制反转（IoC）的技术促进了松耦合。当应用了IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反??不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。面向切面??Spring提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（）管理）进行内聚性的开发。应用对象只实现它们应该做的??完成业务逻辑??仅此而已。它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。容器??Spring包含并管理应用对象的配置和生命周期，在这个意义上它是一种容器，你可以配置你的每个bean如何被创建??基于一个可配置原型（prototype），你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例??以及它们是如何相互关联的。然而，Spring不应该被混同于传统的重量级的EJB容器，它们经常是庞大与笨重的，难以使用。框架??Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中，应用对象被声明式地组合，典型地是在一个XML文件里。Spring也提供了很多基础功能（事务管理、持久化框架集成等等），将应用逻辑的开发留给了你。所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种模块提供了基础支持。（2）Spring的历史Spring的基础架构起源于2000年早期，它是RodJohnson在一些成功的商业项目中构建的基础设施。在2002后期，RodJohnson发布了《ExpertOne-on-OneJ2EEDesignandDevelopment》一书，并随书提供了一个初步的开发框架实现??interface21开发包，interface21就是书中阐述的思想的具体实现。后来，RodJohnson在interface21开发包的基础之上，进行了进一步的改造和扩充，使其发展为一个更加开放、清晰、全面、高效的开发框架??Spring。2003年2月Spring框架正式成为一个开源项目，并发布于SourceForge中。（3）Spring的使命J2EE应该更加容易使用。面向对象的设计比任何实现技术（比如J2EE）都重要。面向接口编程，而不是针对类编程。Spring将使用接口的复杂度降低到零。（面向接口编程有哪些复杂度？）代码应该易于测试。Spring框架会帮助你，使代码的测试更加简单。JavaBean提供了应用程序配置的最好方法。在Java中，已检查异常（Checkedexception）被过度使用。框架不应该迫使你捕获不能恢复的异常。2．控制反转IoCIoC全名InversionofControl，如果中文硬要翻译过来的话，就是「控制反转」。初看IoC，从字面上不容易了解其意义，我觉得要了解IoC，最好先从DependencyInversion开始了解，也就是依赖关系的反转。DependencyInversion在面向对象的设计原则之依赖倒置原则（DIP，DependenceInversionPrinciple）中有着清楚的解?。简单的说，在模块设计时，高层的抽象模块通常是与业务相关的模块，它应该具有重用性，而不依赖于低层的实现模块，例如如果低层模块原先是软盘存取模式，而高层模块是个存盘备份的需求，如果高层模块直接叫用低层模块的函式，则就对其产生了依赖关系。请看下面的例子：voidCopy(){intc;while((c=ReadKeyboard())!=EOF)WritePrinter(c);}这是僵化和不易改动的例子，为什么呢？很显然，如果我还要将内容输出到磁盘上（如下图所示），那么我们必须改动Copy的内容，并进行重新的测试和编译。改动后的程序如下所示：enumOutputDevice{printer,disk};voidCopy(OutputDevicedev){intc;while((c=ReadKeyboard())!=EOF)if(dev==printer)WritePrinter(c);elseWriteDisk(c);}如果要继续添加别的输入或输出方式，该程序还是无法重用，要对此程序进行修改才能继续使用。利用依赖倒置原则（DIP），可以解决这个问题。DIP原则，可以从2点来解读：第1点：高层模块不依赖底层模块，两者都依赖抽象第2点：抽象不应该依赖于细节，细节应该依赖于抽象上面所讲的例子如果用DIP原则，结果如下classReader{public:virtualintread()=0;};classWriter{public:virtualvoidwrite(int)=0;};voidCopy(Reader&r,Writer&w){intc;while((c=r.read())!=EOF)w.write(c);}这样一来，如果要添加新的输入或输出设备时只要改动相应的类（classReader,Writer，利用多态来解决上面的问题）就可以了，而其它的程序都不用改动。这就是依赖倒置原则的基本内涵。在软件设计和构建中我们要遵循“高内聚、低偶合”的原则。那么，依赖对于我们来说究竟是好事还是坏事呢？首先应该明白的是，类之间如果是零偶合的状态是不能够构建应用程序的，只能构建类库。但是由于人类的理解力和可控制的范围有限，大多数人难以理解和把握过于复杂的系统。把软件系统划分成多个模块，可以有效控制模块的复杂度，使每个模块都易于理解和维护。但在这种情况下，模块之间就必须以某种方式交换信息，也就是必然要发生某种耦合关系。如果某个模块和其它模块没有任何关联（哪怕只是潜在的或隐含的依赖关系），我们就几乎可以断定，该模块不属于此软件系统，应该从系统中剔除。如果所有模块之间都没有任何耦合关系，其结果必然是：整个软件不过是多个互不相干的系统的简单堆积，对每个系统而言，所有功能还是要在一个模块中实现，这等于没有做任何模块的分解。因此，模块之间必定会有这样或那样的依赖关系，永远不要幻想消除所有依赖。但是，过强的耦合关系（如一个模块的变化会造成一个或多个其他模块也同时发生变化的依赖关系）会对软件系统的质量造成很大的危害。特别是当需求发生变化时，代码的维护成本将非常高。所以，我们必须想尽办法来控制和消解不必要的耦合，特别是那种会导致其它模块发生不可控变化的依赖关系。依赖倒置、控制反转就是人们在和依赖关系进行艰苦卓绝的斗争过程中不断产生和发展起来的。我们下面来继续一步一步的说明这个问题。看下面的程序：#include<floppy.h>....voidsave(){....saveToFloppy()}}由于save()程序依赖于saveToFloppy()，如果今天要更换低层的存储模块为Usb碟，则这个程序没有办法重用，必须加以修改才行，低层模块的更动造成了高层模块也必须跟着更动，这不是一个好的设计方式，我们希望模块都依赖于模块的抽象，这样才可以重用高层的业务设计。如果以面向对象的方式来设计，依赖倒置（DependencyInversion）的解释变为程序不应依赖实现，而是依赖于抽象，实现必须依赖于抽象。我们来看看下面这个Java程序：BusinessObject.javapublicclassBusinessObject{privateFloppyWriterwriter=newFloppyWriter();....publicvoidsave(){...writer.saveToFloppy();}}publicclassFloppyWriter{....//相应的写盘的代码}在这个程序中，BusinessObject的存盘依赖于实际的FloppyWriter，如果今天我们想要将存盘改为存至Usb碟，我们必须修改或继承BusinessObject进行扩展，而无法直接使用BusinessObject。浩劫只是刚刚开始，这时，你一定和我一样在期待着救世主的早日降临??接口（Interface）。你一定会说，面向对象的设计原则已经告诉我们了啊，“要针对接口编程”，你为什么不用呢？好，我们采用这个原则进行编程：什么是接口？接口定义了行为的协议，这些行为在继承接口的类