2.5.2
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
Table of Contents
即使有好工具和好技术,开发软件仍然是比较困难的。有一些平台,它们包打天下, 但实际上很沉重、难以控制,在开发过程中效率不高,却让开发软件变得更加困难。 Spring为编写企业应用程序提供了轻量的解决方案,同时仍然支持使用声明式事务、 用RMI或web service远程调用、以及使用多种方式来将数据持久化到数据库。Spring提供了全功能的 MVC framework, 以及透明集成AOP到你的软件中的能力。
Spring可能是你的企业应用程序所需要的一站式解决方案, 但Spring仍然是模块化的,允许你只使用你所需的哪些部分,而无需附加上其他部分。 你可以使用 IoC容器,在其上使用Struts,但是你也可以选择使用 Hibernate 整合代码或者 JDBC 抽象层。 我们将Spring设计为非侵入式的(并且以后也是如此),这意味着应用基本上不需要依赖框架本身 (或者肯定是最小的,取决于所使用的部分)。
这份手册提供Spring的功能参考指南。由于本文档也需要大量的工作,如果你有任何要求或者意见, 请发送到用户邮件列表,或者提交到http://forum.springframework.org/支持论坛。
另外,必须感谢Christian Bauer(来自Hibernate团队) ,他改写了DocBook-XSL软件来创建Hibernate参考手册,我们才得以创建这份文档。 也需要感谢Russell Healy为本手册的部分内容进行的详细而极富价值的审核。
Java应用(从applets的小范围到全套n层服务端企业应用)是一种典型的依赖型应用,它就是由一些互相适当地协作的对象构成的。因此,我们说这些对象间存在依赖关系。
Java语言和java平台在架构应用与建立应用方面,提供着丰富的功能。从非常基础的基本数据类型和Class(即定义新类)组成的程序块,到建立具有丰富的特性的应用服务器和web框架都有着很多的方法。一方面,可以通过抽象的显著特性让基础的程序块组成在一起成为一个连贯的整体。这样,构建一个应用(或者多个应用)的工作就可以交给架构师或者开发人员去做。因此,我们就可以清晰的知道哪些业务需要哪些Classes和对象组成,哪些设计模式可以应用在哪些业务上面。 例如:Factory、Abstract Factory、Builder、Decorator 和 Service Locator 这些模式(列举的只是少数)在软件开发行业被普遍认可和肯定(或许这就是为什么这些模式被定型的原因)。 这固然是件好事,不过这些模式只是一个有名字的,有说明的,知道最好用在什么地方的,解决应用中什么问题的最佳实践而已。 在本章节的最后,用“... 说明 ...”给出了模式说明。 通常,模式书籍与wikis通常都列出了你可以获得的最佳实践,不过,希望你思考之后,在你自己的应用中 实现自己的模式。
Spring的IoC控件主要专注于如何利用classes、对象和服务去组成一个企业级应用,通过规范的方式,将各种不同的控件整合成一个完整的应用。Spring中使用了很多被实践证明的最佳实践和正规的设计模式,并且进行了编码实现。如果你是一个,构架师或者开发人员完全可以取出它们集成到你自己的应用之中。这对于那些使用了Spring Framework的组织和机构来说,在spring基础上实现应用不仅可以构建优秀的,可维护的应用并对Spring的设计进行验证,确实是一件好事情。
Spring框架包含许多特性,并被很好地组织在下图所示的六个模块中。本节将依次介绍每个模块。

Spring框架概述
Core 封装包是框架的最基础部分,提供IoC和依赖注入特性。这里的基础概念是BeanFactory,它提供对Factory模式的经典实现来消除对程序性单例模式的需要,并真正地允许你从程序逻辑中分离出依赖关系和配置。
Context(上下文) 封装包构筑于Core封装包的坚固基础上:它提供了用一种框架风格的方式来访问对象,有些像JNDI注册表。Context封装包继承了beans包的功能,还增加了国际化(I18N)(用于规范resource bundle),事件传播,资源装载,以及透明创建上下文,例如通过servlet容器。
DAO 提供了JDBC的抽象层,它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。 并且,JDBC 封装包还提供了一种比编程性更好的声明性事务管理方法,不仅仅是实现了特定接口,而且对所有的POJOs(plain old Java objects)都适用。
ORM 封装包提供了常用的“对象/关系”映射APIs的集成层。 其中包括JPA、JDO、Hibernate 和 iBatis 。利用ORM封装包,可以混合使用所有Spring提供的特性进行“对象/关系”映射,如前边提到的简单声明性事务管理。
Spring的 AOP 封装包提供了符合 AOP Alliance规范的面向方面的编程(aspect-oriented programming)实现,让你可以定义,例如方法拦截器(method-interceptors)和切点(pointcuts),从逻辑上讲,从而减弱代码的功能耦合,清晰的被分离开。而且,利用source-level的元数据功能,还可以将各种行为信息合并到你的代码中,这有点象.Net的attribute的概念。
Spring中的 Web 包提供了基础的针对Web开发的集成特性,例如多方文件上传,利用Servlet listeners进行IoC容器初始化和针对Web的application context。当与WebWork或Struts一起使用Spring时,这个包使Spring可与其他框架结合。
Spring中的 MVC 封装包提供了Web应用的Model-View-Controller(MVC)实现。Spring的MVC框架并不是仅仅提供一种传统的实现,它提供了一种 清晰的 分离模型,在领域模型代码和web form之间。并且,还可以借助Spring框架的其他特性。
借助搭积木方式来解释一下各种情景下使用Spring的情况,从简单的Applet一直到完整的使用Spring的事务管理功能和Web框架的企业应用。

典型的完整Spring Web应用
通过用Spring的 声明事务管理特性,Web应用可以做到完全事务性,就像使用EJB提供的那种容器管理的事务一样。 所有自定义的业务逻辑可以通过简单的POJO来实现,并利用Spring的IoC容器进行管理。对于其他的服务,比如发送email和不依赖web层的校验信息,还可以让你自己决定在哪里执行校验规则。 Spring本身的ORM支持可以和JPA、Hibernate、JDO以及iBatis集成起来,例如使用Hibernate,你可复用已经存在的映射文件与标准的Hibernate SessionFactory 配置。用控制器去无缝整合web层和领域模型,消除对 ActionForms 的依赖,或者避免了其他class为领域模型转换HTTP参数的需要。

使用了第三方框架的Spring中间层
有的时候,现有情况不允许你彻底地从一种框架切换到另一种框架。然而,Spring却 不需要 强制你使用它的全部,Spring不是一种 全有全无 的解决方案。 如果,现有的应用使用了WebWork、Struts、Tapestry或其他的UI框架作为前端程序,完全可以只与Spring的事务特性进行集成。 只需要使用 ApplicationContext 来挂接你的业务逻辑和通过 WebApplicationContext 来集成你的web层前端程序。

远程使用场景
当你需要通过WebService来访问你的现有代码时,你可使用Spring提供的 Hessian-、Burlap-、Rmi- 为前缀的接口或者 JaxRpcProxyFactory 这个代理类。你会发现,远程访问现有应用程序不再那么困难了。

EJBs-包装现有的POJOs
Spring还为EJB提供了 数据访问和抽象层,让你可以复用已存在的POJO并将他们包装在无状态SessionBean中,以便在可能需要声明式安全(EJB中的安全管理,译者注)的非安全的Web应用中使用。
如果你已经用了一段时间的Spring Framework,那你将发现Spring经历了两次大的修订: 一次是2006年10月发布的Spring 2.0, 另一次是2007年11月发布 Spring 2.5 。
本章是对Spring 2.0与2.5新特性与改进特性的向导。我们希望提供一个高阶的概述使那些有经验的Spring架构师与开发人员能很快熟悉Spring 2.x的新功能。 如果想了解关于特性更多更深层的信息,请参考在本章里超链接的相应部分。
Spring 2.0 相当大的改进之一就是Spring的IoC容器。
Spring上个版本的IoC容器支持两个不同的bean作用域(单例与原型)。Spring 2.0改进了这一点,不仅提供了一些依赖于Spring部署环境(比如说,在web环境中的request和session作用域bean)的额外的作用域,而且提供了所谓的'钩子'('hooks')(因为找不到更好的表达)使Spring用户可以创造自己的作用域。
应该注意的是,即使单例与原型作用域beans的基本(内在)实现发生了变化,上述变化对最终用户来说是透明的...现有的配置不需要改变或放弃。
在标题为 Section 3.4, “Bean的作用域” 的部分有对新增的作用域与原有作用域的详细描述。
多亏了新的基于XML Schema的XML配置语法的产生,Spring的XML配置变的更加简单了。如果你想充分利用Spring提供的新标签(Spring团队当然建议你这么做,因为他们使配置变的不再繁琐,更加易于阅读),请阅读标题为 Appendix A, XML Schema-based configuration 的部分。
相关提示,有一个新的更新过的Spring 2.0的DTD。如果你不能使用基于Schema的XML配置,你可以使用它。下面给出了DOCTYPE声明,如果有兴趣的读者可以详细阅读Spring 2.0发布包的 'dist/resources'目录中的'spring-beans-2.0.dtd' DTD。
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
XML配置不仅更加易于书写,而且也具有可扩展性。
这里'可扩展性'的含义是,作为一个应用程序开发人员,或着(更可能)作为第三方框架或产品的供应商,可以开发自定义标签,供其他开发人员把这些标签嵌入到自己的Spring配置文件里。你可以在组件的特定配置中定义你自己的DSL(domain specific language,这个词在这里用得比较宽泛)。
对于开发人员或者在项目中运用Spring的企业架构师来说,实现自定义Spring标签可能不是每个人都感兴趣的。我们期待着第三方供应商能够对开发在Spring配置文件里使用的自定义配置标签予于足够的关注。
可扩展的配置机制在 Appendix B, Extensible XML authoring 里有更充分的描述。
Spring 2.0 引入了一些用于配置的annotation, 包括 @Transactional, @Required and @PersistenceContext /@PersistenceUnit.
Spring 2.5 引入了用于配置的完整的Annotation集合: @Autowired,以及对JSR-250注解@Resource, @PostConstruct and @PreDestroy的支持。
Annotation驱动的bean 配置在Section 3.11, “基于注解(Annotation-based)的配置”中讨论。也请查阅对Spring MVC的annotation的支持Section 2.5.3, “基于Annotation的控制器”。
Spring2.5 引入了组件搜索功能:在classpath中自动搜索带有annotation的组件。典型的,下列组件类会注解为stereotype: @Component, @Repository, @Service, @Controller. 取决于程序的上下文配置,这些组件会被自动搜索到,并且转变为Spring bean定义,而不需要为每个类都进行明确的配置。
Annotation-driven bean configuration is discussed in Section 3.12.1, “@Component和更多典型化注解”.
Annotation驱动的bean配置在Section 3.12.1, “@Component和更多典型化注解”讨论。
Spring 2.0在AOP上有很大的改进。Spring AOP框架本身就十分易于用XML配置,不再那么繁琐;Spring 2.0集成了AspectJ 切入点(pointcut)语言和 @AspectJ 切面(aspect)声明类型。 标题为 Chapter 6, 使用Spring进行面向切面编程(AOP) 的部分专门描述这个新支