1.3 使用方案

前面描述的模块使得 Spring 可以在很多方案中作为业务逻辑实现的选择，从 applet 到 使用了 Spring 的事务管理功能和 Web 框架整合，功能完善的企业级应用程序。

image

典型地功能完善的 Spring Web 应用

Spring 的声明式事务管理特性（11.5 节）使得 Web 应用程序可以全部事务化，就好像

使用了 EJB 容器管理的事务。全部的自定义业务逻辑可以使用简单的 POJO 来实现并且被 Spring 的 IoC 容器来管理。其它的服务包含对发送邮件的支持，验证对 Web 层独立，这可以 让你选择在哪里执行验证规则。Spring 的 ORM 支持对 JPA，Hibernate,JDO 和 iBatis 进行了整合；比如，当使用 Hibernate 时，你可以继续使用已有的映射文件和标准的 Hibernate 的 SessionFactory 配置 。表 单控 制器 无缝 地整 合了 Web 层 和领 域模 型， 也去 除了 ActionForm 或其它为领域模型转换 HTTP 参数的类的需要。

image

使用了第三方 Web 框架的 Spring 中间层 有时，开发和运行环境并不允许你完全转换到一个不同的框架中。Spring Framework 不强制你使用其中的部分；它并不是一个所有或没有的方案。已有使用了 WebWork，Struts， Tapestry 或其它 UI 框架构建的前端应用程序也可以使用基于 Spring 的中间层来进行整合， 这 就 允 许 你 去 使用 Spring 的 事 务 特 性 。 你 仅 仅 需 要 做 的 是 给 业 务 逻 辑 装 上 ApplicationContext，对整合的 Web 层使用 WebApplicationContext。

image

远程调用使用方案

当你需要通过 Web Service 访问已有的代码时，你可以使用 Spring 的 Hessian-， Burlap-，Rmi-或 JaxPpcProxyFactory 类。对已有的应用程序开启远程访问并不困难。

image

EJB – 包装已有的 POJO

Spring Framework 也提供了对企业级 Java Bean（EJB，译者注）的访问和抽象层（第 21 章），这就可以重用已有的 POJO，可以扩展、包装它们到无状态会话 bean，不安全的 Web 应用程序可能也需要声明式安全。

1.3.1 依赖管理和命名规约

依赖管理和依赖注入是不同的概念。要在应用程序中添加 Spring 的优雅特性（比如依 赖注入），你需要放置所需的类库（jar 文件），并且添加到运行时环境的类路径中，通常在 编译时也是需要这些类库文件的。这些依赖不是注入的虚拟组件，而是文件系统（通常来说 是这样）上的物理资源。依赖管理的过程包括定位资源，存储它们，并将它们添加到类路径 中。依赖可以是直接的（比如应用程序在运行时需要 Spring），或者是间接的（比如应用程 序需要的 commons-dbcp 组件还依赖于 commons-pool 组件）。间接的依赖也被认为是“过 度的”，而且那些依赖本身就难以识别和管理。

如果你决定使用 Spring，那么你需要获得 Spring 的 jar 包，其中要包括你所需要使用的 Spring 的模块。为了使用的便捷，Spring 被打包成各个模块的集合，尽可能地分离其中的相 互依赖，那么如果你不想编写 Web 应用程序，就不需要添加 spring-web 模块的 jar 包。要参 考 Spring 模 块 的 库 ， 本 指 南 使 用 了 一 个 可以 速记 的 命 名 规 约 ， spring- 或者 spring-.jar ，这里的“ * ” 代 表 了 各 模 块 的 短 名 称 （ 比 如 ， spring-core ， spring-webmvc，spring-jms 等）。实际上 jar 文件命名或许就是这种形式的（参考下 面的示例），但也有可能不是这种情况，通常它的文件名中还包含一个版本号（比如， spring-core-3.0.0.RELEASE.jar）。

通常，Spring 在四个不同的地方发布组件：

  • 在社区下载点 http://www.springsource.org/dow nloads/comm unity。在这儿你可以找到所 有的 Spring jar 包，它们被压缩到一个 zip 文件中，可以自由下载。这里 jar 包的命名从 3.0 版本开始，都以 org.springframework.*-.jar 格式进行。

  • Maven 的中央库，也是 Maven 默认检索的资源库，它并不会检索特殊的配置来使用。 很多 Spring 所依赖的常用类库也可以从 Maven 的中央库中获得，同时 Spring 社区的绝大多数用户都使用 Maven 作为依赖管理工具，这对于他们来说是很方便的。这里的 jar 包的命名规则是 spring-*-.jar 格式的，并且 Maven 里的 groupId 是 org.springframework。

  • 企业级资源库（Enterprise Bundle Repository，EBR），这是由 SpringSource 组织运营的， 同时也提供了和 Spring 整合的所有类库。对于所有 Spring 的 jar 包及其依赖，这里也有 Maven 和 Ivy 的资源库，同时这里还有很多开发人员在使用 Spring 编写应用程序时能用到的其它大量常用类库。而且，发布的版本，里程碑版本和开发版本也都部署在这里。 这 里 jar 文 件 的 命 名 规 则 和 从 社 区 下 载 的 （org.springframework.*-<version>.jar）一致，并且所依赖的外部类库（不 是来自 SpringSource 的）也是使用的这种“长命名”的形式，并以 com.springsource 作为前缀。可以参考 FAQ 部分获取更多信息。

  • 在 Amazon S3 为开发和里程碑版本发布（最终发布的版本这里也会有）而设置的公共Maven 资源库。Jar 文件的名称和 Maven 中央库是一样的，那么这里是获取 Spring 开发版本的地方，其它的类库是部署于 Maven 中央库的。 那么，首先你要决定的事情是如何管理这些依赖：很多人使用自动化的系统，比如 Maven 和 Ivy，但是你也可以手动下载所有的 jar 文件。当使用 Maven 或 Ivy 获取 Spring 时，之后你就需要决定从哪里来获取它们。通常来说，如果你关注 OSGi 的话，那么就使用 EBR，因为 它对所有的 Spring 依赖兼容 OSGi，比如 Hibernate 和 Freemarker。如果对 OSGi 不感兴趣， 那么使用哪个下载都是可以的，但是他们也各有利弊。通常来讲，为你的项目选择一个或者备用的一个；但是请不要混用。因为相对于 Maven 中央库而言，EBR 组件非常需要一个不同的命名规则，那么这就特别重要了。

表 1.1 Maven 中央库和 SpringSource EBR 资源库的比较