Spring参考手册Word文件下载.docx
《Spring参考手册Word文件下载.docx》由会员分享，可在线阅读，更多相关《Spring参考手册Word文件下载.docx（11页珍藏版）》请在冰豆网上搜索。
●使Java方法可以执行数据库事务而不用去处理事务API
●使本地Java方法可以执行远程过程而不用去处理远程API
●使本地Java方法可以拥有管理操作而不用去处理JMXAPI
●使本地Java方法可以执行消息处理而不用去处理JMSAPI
2.1依赖注入和控制反转
Java应用程序——一个宽松的专业术语，小到一个Appletes大到运行在n层服务器上的企业级程序—通常由互相协作的对象而形成的适当的应用程序。
因此在应用中的各种对象之间都会有依赖关系。
虽然Java平台提供了丰富的应用程序开发功能，但是他缺乏将基本模块组织成一个连贯的整体的技术手段，而是把这些任务留待给开发人员解决。
当然，你可以使用各种设计模式，包括工厂模式，抽象工厂模式，构建模式，装饰器模式，还有服务定位器去组织这些多样的类和对象实例从而构成一个应用程序。
然而，这些模式是如此的简单：
一个使用特定名称的最佳实践，描述了它是干什么的，在哪里使用它，解决的问题是什么等等。
模式是形式化的最佳实践,你必须在应用程序中实现自己的业务逻辑。
Spring框架的控制反转（IoC）组件提供一个成文的解决方案—将不同部分整合成一个完全能协作运行的应用程序—解决了这个问题。
spring框架将那些形式化设计模式总结为一流的对象，你可以在你的应用程序中直接使用他们。
众多组织和机构使用Spring框架以这种方式来工程师健壮的、可维护的应用程序。
2.2模块
Spring框架的功能组织成大约20个模块，这些模块分为核心容器、数据访问/集成、网络、AOP（面向切面的编程）、工具、和测试，如下图所示。
2.2.1核心容器
核心容器包括：
Core，Beans,Context，和表达式语言
Core和Beans模块是框架的基础部分，拥有IoC和依赖注入的特性。
BeanFactory是一个复杂的工厂模式的实现，它消除了对于程序化的单例对象的需求，并且允许你将配置信息和规范的依赖关系从你的实际代码逻辑中解耦出来。
Context模块是以Core和Beans模块为基础构建的，提供一种框架式的对象访问方式，就行JNDI注册一样。
Context模块从Beans模块继承了它的特性，并增加了对于国际化的支持（用于例如资源包的场景），事件传播，资源配置还有透明的上下文，例如一个Servlet容器。
Context模块同样支持JavaEE特性，例如EJB，JMX还有基本的远程操作。
ApplicationContext接口是Context模块的核心。
表达式语言模块是一种在运行时操作和查询对象的强有力的表达式语言，其语法类似统一的EL语言，但是SpEL提供了额外的功能。
2.2.2数据防问/集成
数据访问/集成层包括：
JDBC、ORM、OXM、JMS和事务等模块
JDBC模块提供了一个去除了单调乏味的JDBC代码和解析数据库供应商特定的错误代码的JDBC抽象层。
ORM模块将热门的对象关系映射API集成，包含JPA，JDO和Hibernate。
使用ORM包你可以将spring提供的其他特性与所有的ORM框架结合，例如前面提到的简单的声明式事务管理。
OXM模块提供了一个支持对象到XML映射的抽象层，包括JAXB、Castor、XMLbeans和Xstream。
JMS模块支持生产和消费的信息的特性。
事务模块支持针对那些实现了特定接口和所有的POJOs类的编程式和声明式的事务管理模式
2.2.3Web
网络层包括Web、Web-Servlet、Websocket和Web-Portlet模块
Spring的Web模块提供基本的以网络为中心的集成特性，例如文件上传，通过使用Servlet监听器初始化IoC，面向web应用程序上下文。
它还包含Spring的远程支持的web部件。
Web-Servlet包含为web应用程序的spring的MVC实现，springMVC框架将web表单和模型对象完全分离，并集成了spring框架的其他特性。
Web-Portet模块用于portlet环境和Web-Servlet模块的功能镜像的MVC实现。
2.2.4AOP和工具
Spring的AOP模块提供了AOPAlliance-compliant（AOP兼容联盟）的一个面向切面编程的实现，并允许你自己定义，比如，方法拦截器和完全隔离代码的切入点（用于那些需要分离出来的功能实现），使用源码级别的元数据功能，你也可以在你的代码中加入行为信息，类似于.Net属性设置。
单独的Aspects模块提供了与AspectJ的集成。
工具模块提供了类工具的支持和应用于某些具体的应用程序服务器的类加载器实现。
2.2.5测试
测试模块支持使用Junit或这TestNG来测试Spring组件。
能够持续加载Spring应用上下文，并对其进行缓存，同时也支持使用模拟对象的方式进行隔离测试你的代码。
2.3使用场景
前面所提到的构建模块说明在很多场景下Spring都是一个合理的选择，从以applets为例的小应用程序到成熟的企业级应用程序都可以使用Spring的事务管理功能和Web框架的集成。
Spring的声明式事务管理特性使web应用程序完全事务化，就像使用EJB容器管理的事务。
你的所有业务逻辑都可以通过简单POJOs实现并且托管于Spring的IoC容器。
其他的服务包括发送邮件和独立于网络层的验证规则，由此你可以选择验证规则作用于哪里。
Spring的ORM支持JPA、Hibernate和JDO的集成；
例如当使用Hibernate使，你可以继续使用你存在的映射文件和标准的Hibernate的SessionFactory配置。
表单控制器将web层与领域模型层无缝集成，并且去除了ActionForms或者那些用于将HTTP参数转换为领域模型的值对象（VO）的类。
在某些情况下不允许你完全地迁移到另一个框架。
Spring框架并没用强迫你将其所用东西运用到你的项目中，它不是一个孤注一掷的解决方案。
现有的基于Struts、Tapestry、JSF或者其他的UI框架的前端，可以集成一个基于Spring的中间件，它允许你使用Spring事务功能。
你只需要使用ApplicationContext和WebApplicationContext组织你的业务逻辑从而集成到你的Web层。
当你需要通过web服务访问现有的代码，你可以使用Spring的Hessian-,Burlap-,Rmi-或者JaxRpcProxyFactory类。
远程服务的访问将不再是困难。
Spring框架也为企业级JavaBeans提供了一个访问和抽象层，使你能够重用已有的POJOs，并且将他们包装在无状态的会话Beans中用于可伸缩的自动防故障的web应用程序，一般这些程序可能需要声明式的安全保障。
2.3.1依赖管理和命名约定
依赖管理和依赖注入是不同的。
为了获取Spring的优良特性（例如依赖注入），你需要收集所有需要的库（Jar文件），并且在编译、运行的时候将它们放到你的类路径中。
这些依赖不是被注入的虚拟组件，而是文件系统中的物理资源（通常情况下是这样的）。
依赖管理的过程包括定位那些资源，存储它们并将他们加入类路径。
依赖的有直接（如我的程序在运行期依赖于Spring）和间接（如我的程序依赖于commons-dbcp，而commons-dbcp有依赖于commons-pool）这两种形式。
间接的依赖也被称为“传递”，它是最难识别和管理的依赖。
如果你将要使用Spring，你需要复制那些包含你需要的Spring功能的jar包。
为了使这个过程简单，Spring被打包成一组模块，这些模块尽可能的分开依赖关系。
例如，如果不想写一个web应用程序，你就不需要引入spring-web模块。
为了在本指南中标记Spring库模块我们使用了速记命名约定spring-*或者spring-*.jar，其中*代表模块的短名（比如spring-core,spring-webmvc,spring-jms等）。
实际的jar包名，通常是用模块名字和版本号级联（如spring-core-4.1.4.BULD-SNAPSHOT.jar）。
每一个发行版本将会被放到下面的位置：
●MavenCentral（Maven中央仓库），这是Maven查询的默认库，不需要任何特殊的配置就能使用。
许多常用的Spring的依赖库也存在于MavenCentral，并且Spring社区的很大一部分都是用Maven进行依赖管理，所以这是最方便的，他们的jar命名格式是spring-*-<
vesrsion>
.jar，groupId是org.springframework。
●公共Maven仓库还拥有Spring专有的库。
除了最终的GA版本，还保存开发的快照版和里程碑版。
JAR文件的名字很MavenCentral相同的形式，所以这是让Spring的开发版本使用其他部署在MavenCentral库的一个有用的地方。
该库还包含一个用于发布的zip文件，包含所有的Springjar包方便下载。
因此你的首要事是决定如何管理你的依赖：
我们一般建议使用一个自动系统，就像Maven，Gradle或者Ivy，当然你也可以通过下载自行管理。
我们将在这一章节的后面部分进行详细的指导。
Spring依赖和依赖于Spring
尽管Spring对于非常广泛的企业级业务和其他额外的工具提供了集成和支持，但是它力图将它的强制性依赖降到最低：
你不必定位和下载（或者自动化获取）很大数量的jar库而仅仅只是为了在简单的场景中使用Spirng。
对于基本的依赖注入只需要一个外部的强制性依赖，并且只是用于日志（见下面关于日志的描述）。
接下来我们将一步一步介绍如何配置依赖Spirng的程序。
首先是通过Maven，之后是Gradle，最后是Ivy。
其中如果有任何不清楚的，可以参考你的依赖关系管理系统的相关文档，或者查看一些示例代码-Spring本身是使用Gradle来管理依赖的。
并且我们的示例大多数也是使用Gradle或Maven。
Maven依赖管理
如果你使用Maven的依赖管理，你甚至不需要明确提供日志依赖。
例如，要创建一个应用程序的上下文和使用依赖注入来配置应用程序，你的Maven依赖将看起来像这样：
如上图所示，注意scope节点可以被设置为runtime如果你不需要编译SpringAPIs，这通常是基本的依赖注入的案例。
以上是使用Maven中央仓库的使用示例。
为了使用SpringMaven仓库（例如里程碑版或开发者快照版），你需要在你的Maven配置指定仓库位置。
用于发布版：
用于里程碑版：
用于快照版：
Maven“BillOfMaterials”依赖
当使用Maven时有可能不小心使用不同版本的Spring依赖。
例如，你可能发现一个第三方库，或者另外一个Spring项目，使用了较早的发布版本的传递依赖。
如果你忘记了显式声明一个直接依赖，各种问题将出现。
为了克服这些问题，Maven支持“BillOfMaterials”（BOM）的依赖概念。
dependencyManagement部分引入spring-framework-bom来确保所有Spring依赖（包括直接和间接依赖）是同一个版本。
加入BOM的益处在于你不必再指定<
version>
属性，而此时Springframework的依赖将是如下图所示：
Gradle依赖管理
用Gradle使用Spring，在repositories中填入适当的URL：
你可以让repositories的URL在/release、/milestone、/snapshot之间切换，一旦指定repositories，就可以通过一下方式声明依赖：
Ivy依赖管理
如果你更喜欢Ivy管理依赖也有类似的配置选项。
配置Ivy，将指向Spring的库添加下面的解析器到你的ivysettings.xml:
你可以让root的URL在/release、/milestone、/snapshot之间切换，一旦指定root，就可以通过一下方式声明依赖：
分发zip文件
尽管使用构建系统管理依赖是推荐的方式，仍然可以下载分发的zip文件。
分发的zip文件是发布到SpringMaven仓库（这是为了便利，在下载这些文件的时候你不需要Maven或其他构建系统）。
下载一个zip，在Web浏览器打开http:
//repo.spring.io/release/org/springframework/spri
ng，选择适当的文件的版本。
2.3.2日志
对于Spring日志是一个非常重要的依赖，原因有三点:
a）这是唯一的外部强制依赖，b）每位程序员都想查看使用的工具的输出，c）Spring集成的所有工具都选择了日志依赖。
开发者都有的一个目标通常是希望在整个应用中有一个统一的日志配置，囊括了所有的外部组件。
因为有如此多的日志框架使之相对较难实现。
Spring的强制日志依赖是JakartaCommonsLoggingAPI（JCL）。
我们编译JCL同时也让JCL的Log对象对SpringFramework的扩展类可见。
Spring的所有版本都须使用相同的日志框架，这一点对于用户来说非常重要：
迁移就会变得容易因为向后兼容性的保留，即使扩展Spring的应用程序。
为达到此目的我们的做法是让Spring的其中一个模块显式地依赖commons-logging（JCL的规范实现），之后让其他所有的模块都在编译期依赖该模块。
假如你正在使用Maven，并且想知道你在哪里使用了commons-logging依赖，答案就是来自于Spring，确切的说是名为spring-core的中心模块。
关于commons-loggin的好处在于你不需要任何东西就能让你应用程序跑起来。
他有一个运行期的检索算法，它会在类路径下熟知的位置找到其他的日志框架，并使用一个它认为适合的日志框架（或者如果需要你可以告诉它该用哪个）。
如果没有一个可用的，那么你就可以获得一个来自于JDK的良好格式的日志（java.util.loggingorJUL的简称）。
大多数情况下，你可以在控制台查看你的Spring应用程序工作和日志，这一点很重要。
不使用commons-logging
不幸的是，common-logging中为最终用户提供便利的运行期检索算法有问题。
如果我们让时光倒流，重新开始一个使用了不同的日志框架的Spring项目。
第一选择或许会是SimpleLoggingFacadeforJava（SLF4J），这个日志框架也被用于许多其他工具通过使用Spring应用到他们的应用程序中。
关闭commons-logging很简单：
只需要保证其在运行期不在类路径下就可以。
就Maven而言你排除依赖就可以，因为Spring依赖声明的方式,你只需要做一次。
现在这个应用程序可能出了点问题，因为在类路径下没有JCLAPI的实现。
因此一个新的配置必须提供。
在接下来的部分我们将为你展示如何提供一个可选的JCL实现，以SLF4J为例。
使用SLF4J
SLF4J是一个更加简洁的依赖，并且在运行期比common-logging更加高效，因为它是在编译期绑定而不是在运行期查找另外的日志框架与其集成。
这也意味着你不得不更加清晰地了解在运行期你想要发生什么，并相应的声明或配置它。
SLF4J对很多通用的日志框架提供了绑定，因此你选择你以前使用过的框架，通过配置绑定到它并管理它。
SLF4J对很多通用的日志框架提供了绑定，包括JCL，他也做了反响工作：
是其他日志框架与它自己的桥梁。
因此在Spring中使用SLF4J你需要通过SLF4J-JCL桥接替代common-logging依赖。
一旦你做了这些，在Spring中的日志调用将被转换为SLF4JAPI的调用，因此如果在你的应用中的其他库也使用了这个API，那么你就有一个唯一的地方来配置和管理日志。
一个通常的选择是将Spring桥接到SLF4J，之后提供从SLF4J到Log4J的显式桥接。
你需要提供4各依赖（和排除存在的common-logging的依赖）：
桥接，SLF4JAPI,Log4J的绑定，Log4J自身的实现。
在Maven中的配置如下图所示：
这看起来好像仅仅为了一个日志就有了很多依赖。
的确是这样的，但它也是可选的。
它在关于类加载器的问题上应该比commons-logging表现的更加的好，值得注意的是，如果在一个严格的容器中，例如OSGi平台，据说这也是一个性能优势，因为绑定是在编译时而不是在运行时。
在SLF4J的用户中还有一个更普遍的选择，那就是直接绑定到Logback，它需要更少的步骤和更少的依赖。
这种方式移除了额外的绑定步骤，因为Logback是SLF4J的直接实现。
因此你只需要依赖两个库（jcl-over-slf4j和Logback）而不是4个。
如果你真想这么做，也许你需要从其他的依赖（非Spring）中移除slf4j-api的依赖，因为你在类路径下只想使用一个版本的那种API。
使用Log4J
很多人为了配置和管理的目的从而使用Log4J作为日志框架。
它是有效且完善的，事实上我们在构建和测试Spring时也是在运行期使用它的。
Spring提供了一些方便配置和初始化Log4J的工具，因此在某些模块中它也是一个可选的编译期的Log4J依赖。
为了让Log4J通过默认的JCL（common-logging）依赖工作，你所需要做的就是将Log4J放在类路径下，并为其提供一个配置文件（在类路径的根路径下的log4j.properties或者log4j.xml）。
针对Maven用户，依赖声明如下图所示：
在控制台输出日志的log4j.properties文件示例：
第二部分Spring4.X的新特性
3．Spring4.0的新特性和增强
2004年，Spring最初版发布。
自那以后最主要的几个版本包括：
Spring2.0提供XML名称空间和AspectJ的支持；
Spring2.5增强了注解驱动的配置；
Spring3.0引入了一个强大的Java5+基础框架代码库，并且拥有诸如基于@Configuration的Java类配置模型的特性。
4.0是Spring框架的最新的主要发布版，首次全面支持Java8特性。
你仍然可以利用较低版本的Java来使用Spring，当然，最低版本现在已经升级到JavaSE6。
我们也利用本次主要版本的机会移除了一些被废弃的类和方法。
升级到Spring4.0的指南在SpringFrameworkGitHubWiki（
3.1改进的上手的经验
最新的Spring.io网站（http:
//spring.io/）提供了一整套“上手”指南让你学习Spring。
你可以在那里了解到本文档第一部分的更详细内容。
这个新网站还提供了一个全面的关于发布在Spring体系下的许多其他项目的概述。
如果你是一个Maven使用者，你也许会对“billofmaterials”的POM文件的益处感兴趣，现在该文件在每个Spring框架发布版都有。
3.2被移除的遗弃包和方法
在4.0版中所有被遗弃的包和很多被遗弃的类和方法已经被移除了。
如果你正在从旧版本Spring升级，你应该确保已经调整了过时API的调用。
查看API异同报告（http:
//docs.spring.io/spring-framework/docs/3.2.4.RELEAS
E_to_4.0.0.RELEASE/）获取完整的改变。
请注意可选的第三方最低依赖也已经上升到2011/2011（即Spring4.0只支持那些在2010年之后发布的版本）：
值得注意的是Hibernate3.6+，EhCache2.1+，Quartz1.8+，Groovy1.8+和Joda-Time2.0+。
升级会员 