几乎每个 J2EE 应用程序都需要访问一个（或多个）关系数据库，因此可以毫不夸张地说，当您准备构建一个 J2EE 应用程序时，所要做的最重要决定之一就是应用程序访问持久性数据的方式：您的持久性策略不仅会决定应用程序的性能，而且对于开发和维护应用程序所需的工作量也会产生重要影响 — 如果您事先没有做出正确的决策，那么在完成应用程序后很难再重新设计。
在本“精通 J2EE 应用程序开发”系列中，我们将介绍两个不同（但相辅相成的）框架，它们既可以协同地也可以独立地帮助您克服访问 J2EE 应用程序中的持久性数据时的复杂性，这两个框架分别是：
- Oracle TopLink，一个强大的对象关系持久性框架，它为面向对象的应用程序提供一个高度灵活、高效率的关系数据访问机制
- Spring Framework，一个领先的开放源代码 J2EE 应用程序框架，根据 Apache 软件许可发布。Spring 为所有体系结构层提供服务，但因其一致的数据访问方法而在可持续性方面尤为强大。您将看到，Spring 的持久性服务层包含一个数据访问对象 (DAO) J2EE 设计模式的实现。
Oracle TopLink 与 Spring 的 DAO 层组合提供了持久保存传统 Java 对象 (POJO)（即 JavaBean、实体 Bean 以及会话 Bean 以外的标准 Java 对象）持久保存到关系数据库的高性能、高效率方法。
该方法是传统的 J2EE 对象持久性解决方案（EJB 2.x 实体 bean）的替代方法，传统的 J2EE 对象持久性解决方案在实际中由于多方面原因而存在不足，包括低效率的编程模型、较低的开发人员生产效率和可测试性。此外，EJB 的查询语言 (EJBQL) 的原始形式（没有专有扩展）功能很有限。但最重要的是，实体 bean 禁止使用实际的面向对象的继承，从而为面向对象的设计带来了太多的限制，因此它们并不适合于持久保存复杂的域模型。（而 POJO 对于创建特定问题域的对象模型尤其有用。）
通过本文介绍的持久性方法，您可以持久保存 POJO 而不会为面向对象的设计带来限制，在我们看来，该方法是一个比 EJB 更好的战略选择（请参见“初现端倪：EJB 3.0 简介”侧边栏）。
尽管本文在一定程度上着重介绍了 TopLink 和 Spring，但它们所广泛代表的技术（对象关系映射、作为 DAO 抽象实现的持久层、通过控制倒置实现的配置分离）为 J2EE 开发人员提供了体系结构方面的经验。此类技术能够持久保存真正面向对象的域模型（记录重要的业务概念）。人们通常认为它们可以实现透明的持久性—对象关系映射产品能够直接操作（使用对象编程语言）关系数据库中存储的数据。
我们将重点介绍其中的某些功能，并提供您可以使用的 J2EE 持久性的一般指南、最佳实践和基本策略，无论您使用什么特定的工具或框架。
首先，我们快速了解一下开发涉及 Java 和关系数据库领域的应用程序所面临的挑战。
通过 Java 自动访问数据的需要
JDBC API 定义了 Java 代码与关系数据库通信的一个标准方法，但它的级别太低无法满足应用程序开发人员高效使用的需要。在 JDBC 上使用一个抽象层（例如，Spring 的 JDBC 程序包或性能良好的内部 JDBC 框架）可以提高 JDBC 编码的效率并降低出错的可能性。
但作为开发人员的您还须执行大量低级日常的工作。例如，在数据库中存取数据需要在 JDBC 预处理语句中设置值和从 JDBC 结果集中提取值。
工作级别比 JDBC 框架略高的抽象工具（如 iBATIS SQL Maps）可以使大部分 JDBC 到 SQL 映射自动化。但开发人员仍需要编写 SQL、检测持久对象何时变“脏”（即与数据库脱离同步）、编写大量 Java 代码来存储对象。
有时，在这样低级的情况下工作比较合适。某些应用程序所需的自动化程度并不比此类方法提供的自动化程度高。而大多数应用程序则不然。它们需要复杂的对象关系映射 (ORM) 工具所提供级别的自动化。
对象关系映射概述
您可能听说过对象关系映射 (ORM)。而且您也可能曾经使用过它；否则，应考虑在您的 Java 或 J2EE 应用程序中使用它。
| “准备构建应用程序时，一个重要的决定是它将如何访问持久数据。”
|
ORM 弥合了所谓的对象关系阻抗失配：设计良好的 Java 应用程序的面向对象的模型（基于对现实世界的事物与概念进行的建模）与数据库模式中的关系模型（基于数学的数据存储方法）之间的鸿沟。这个鸿沟惊人得宽。原始方法（简单地将每个类映射到一个表）在许多方面存在不足。例如：
- Java 对象之间的关系映射为数据库中的联接，但遍历的开销很高，除非对此映射进行优化。
- 对象通常参与继承层级体系（一个有别于关系模型的概念）。
- 标准关系模型不提供可的语言（如 Java）扩展分类。
- 如果查询完全用 SQL 编写，则它们与 Java 对象的关系可能并不明确。
ORM 由持久性框架执行，该框架知道如何查询数据库来检索 Java 对象，并知道如何将这些对象持久保存为它们在数据库表和列中的表示。映射在元数据（通常是 XML 文件）中定义。某些常见工具提供了图形化工具，以便更轻松地生成映射。（TopLink 以其出色的 Mapping Workbench 在这方面处于领先地位。参见图 1。有关更多信息，另请参见“关于 Toplink”侧边栏。）
使用 ORM，自动化不但扩展到将对象映射到数据库行和列，而且还扩展到使用最少数目的 SQL 更新检测脏对象并将数据写回数据库 — 适用于大多数应用程序的要求，而且使用框架可以轻松地满足这些要求。
ORM 的主要好处
ORM 历史悠久，且并不为 Java 所独有。但它在 Java 开发人员中已经变得非常流行。ORM 有很多好处，这些好处综合在一起可以显著提高生产效率。具体体现在：
- 使用 ORM，您不必编写 SQL 来加载和持久保存对象状态。尽管您仍须编写查询，但好的 ORM 工具可以显著简化查询的编写。并且您不再需要编写那些与 JDBC 关联的死板代码。
- ORM 使您可以创建适当的域模型，而无需对关系模型进行太多折衷。您可以主要从对象（而非行和列）的角度进行考虑。
- ORM 可以执行自动的更改检测，从而从开发生命周期中消除容易出错的任务。
- ORM 可以通过降低数据库特有 SQL（可以在 ORM 工具之后进行抽象化）的依赖性来提高数据库之间的可移植性。
ORM 对应用程序性能的影响将视情况而定。对于基于集的更新操作，ORM 可能比直接的 JDBC 要慢，但在许多情况下，ORM 可以对难于进行手动编码的策略（如惰性或急性加载关系）进行微调，因此相对于硬编码的 JDBC 代码而言，ORM 可以提高性能。
有时，ORM 可以像与 TopLink 那样与可以提高性能的复杂缓存机制协同工作。您从缓存获得的好处将取决于您应用程序的本质。
何时及如何选择 ORM
| “由于使用 ORM 解决方案代替 JDBC 而使需要编写的 Java 代码数量减少 30%-50% 一点都不奇怪。”
|
ORM 并非为所有人所接受。尤其是在 .NET 领域中，人们对 ORM 持怀疑态度，而且最近这种怀疑态度在 Java 领域中也有很强的体现。
与其进行推理，倒不如吸收一下我们在各种 J2EE 项目中的实际经验。如果使用得当，ORM 可以显著降低开发投入并提高可维护性。由于使用 ORM 解决方案代替 JDBC 而使需要编写的 Java 代码数量减少 30%-50% 一点都不奇怪。这样可以带来很大的好处，节省的所有投入可以转换到业务特性的实现当中。请不要忽略通过在适当的应用程序、适当的环境中有效使用 ORM 所实现的潜在好处。
使用 ORM 工具所带来的负面影响通常是由于尝试在不适当的场合下使用 ORM 而造成的。只要您不在不适当的情况下强制使用 ORM，那么 ORM 就很可能会产生良好的结果。以下是一些基本的准则：
了解您的目标数据库。不要认为使用 ORM 就可以忽略 SQL 和数据库的锁定模型。对象关系映射是一个简化您的操作的工具 — 即使使用该工具，您仍需要了解所要执行的操作。（未认识到数据库与 SQL 的细微差别可能是导致使用 ORM 出现不良结果的主要原因。）
必须时还应使用 SQL。它在许多情况下的效果很好。好的 ORM 产品（如 TopLink）可以让你发出 SQL 查询。但有时您可能需要执行基于集的更新或调用存储过程。
在使用对象关系映射产品之前请做好调查工作。并非所有 ORM 产品一开始均适用。一定要开发一个反映您需要的测试来评估两个或三个替代产品。本练习将帮助确保您根据性能要求正确使用 ORM。与常规的企业开发一样，必须在项目生命周期的早期减少任何性能风险。此外，ORM 工具的映射功能不应产生大量开销。
了解何时使用 ORM。ORM 尤其适合于单独更新实体并很少执行基于集操作的 OLTP 应用程序，如单独更新客户记录及其关联订单的应用程序。
以及何时不使用它。ORM 并非总是理想的选择。它并不适合于：
- 对大量记录执行频繁的批量更新的应用程序。
- OLAP 应用程序，因为数据库通常提供重要的自带编程机制。（通常，J2EE 可能并不适合于 OLAP。）
- 主要用手动编码的 SQL 和存储过程调用作为检索和更新数据的唯一机制的数据库或操作环境。这种情况下，基于 JDBC 的方法可能是最佳选择；iBATIS SQL Maps 也适合于此类情况。（但应注意，类似 TopLink 的好 ORM 产品可以使用大多数现有模式和存储过程，因此您在此类情况下仍可以考虑 ORM。）
- 由直接的基于 SQL 的方法更好地服务的应用程序，如在很大程度上依赖于已在数据库中编码的（或由完整性约束强制的）业务逻辑的应用程序，以及为用户提供“数据上窗口”（使用户能够编辑数据）的应用程序。在此类应用程序中，ORM 的作用并不大，这是因为对象通常的作用不大（超出了面向对象的概念之外），因此将数据库表建模为域对象的意义并不大。
目前有几个不错的 ORM 工具，包括商业的（例如，最早的 Java ORM 产品 TopLink 以及几个 JDO 实现）和开放源代码的（如 Hibernate 框架或 JDO 实现）。只需从中选择一个工具即可 — 无需自己开发。（以往，开发人员通常开发内部 ORM 框架，而现在这样做没什么意义：不但开销很高，而且效果也决不如普通的商业开放源代码解决方案好。）我们将通过 ORM 框架的用法示例进一步了解如何使用 TopLink，以及由此而带来的生产效率提高。
使用 ORM 工具的示例
使用 TopLink Mapping Workbench 可以定义映射，这些映射持久保存在 XML 文件或 Java 类中。（映射文件可以为人所阅读和编辑。）Mapping Workbench 读取数据库元数据以帮助识别要映射的数据库列名、处理外键关系以及帮助消除映射错误。
在 ORM 产品中有两种主要的查询方法 — 基于字符串的查询语言（如 Hibernate HQL 或 SQL 本身）和基于 API 的表达式语言，如 TopLink 表达式语言（一个强大的用于查询的表达式语言）。尽管表达式语言可能（表面上）显得更为冗长，但它们可以更好地确保语义的正确。
以下是用 Java 编写的基于 TopLink 表达式的查询示例：
ExpressionBuilder builder = new ExpressionBuilder();
Expression exp = builder.get("address").get("country").equal("USA");
exp = exp.and(builder.get("address").get("pCode").equal("27615"));
exp = exp.or(builder.get("address").get("country").equal(""));
session.readAllObjects(Employee.class,exp);
如图 2 和图 3 所示，TopLink Mapping Workbench 还允许您使用图形化方法构建查询。
 |
| 图 2：Oracle TopLink 表达式构创建器
|
 |
| 图 3：使用 TopLink 表达式创建器选择一个查询键
|
TopLink 表达式的功能很强大，并支持 GROUP BY 这样的高级关系概念。但如果您需要“实现底层操作”，也可以在 TopLink 中使用 SQL。
从这些屏幕截图中您可以看到，通过 TopLink Mapping Workbench，您可以在查看数据模型的同时直接定义基于 Java 的查询，而无需编写 Java 代码。这些查询保存在元数据中。
无论您使用哪个特定的 ORM 工具，都必须掌握该产品和您所用的数据库。
Spring Framework、ORM 和持久性
Spring Framework 是一个为所有体系结构层提供服务的主流开放源代码 J2EE 应用程序框架（有关更多信息，请参见“关于 Spring Framework”侧边栏）。
与单层框架（如 Struts）不同，Spring 是一个旨在为应用程序体系结构提供一个清晰的分层方法的应用程序框架。Spring 不影响此体系结构，但简化了好实践的因袭。典型的 Spring 体系结构应用程序由表示层、服务层、DAO 接口和实现层以及持久域对象层组成。
在对象持久性方面，DAO 接口层用于驱动数据访问、实现查询以及其他持久性操作。我们来详细了解一下该层，先着眼于一般方面，然后是如何把 Spring 的 DAO 层用于 ORM 工具（如 TopLink）。
DAO 抽象层的好处
设计良好的 DAO 接口可以完全隐藏服务层对象所特有的持久性技术细节。例如，您可以使用 TopLink 或 Hibernate 实现同一 DAO 接口，而不会影响调用代码。
这样做的效果很好，因为它降低了对特殊 ORM 工具的依赖，并在一定程度上确保将来不会过时。数据访问概念在未来的几年里不会改变，但用于实现 DAO 的技术则不然。更重要的是，它意味着您可以通过使用或模仿 DAO 来轻松测试服务层对象而不必访问数据库。
作为一般机制（遵循 Eric Evans 提出的“信息库”概念）（请参见域驱动的设计，此处没有 Spring 特有的事物），DAO 接口通常提供了以下类型的方法：
- 查找器用于检索持久对象实例。查找器通过对象关系映射工具的查询接口实现。
- 保存方法，用于持久保存新对象
- 删除方法，用于从数据库中删除持久对象。
- 聚合函数，用于计数的方法或其他聚合函数。查询数据库获得聚合通常比迭代大量持久性实体要快得多。
进一步了解 Spring 的 DAO 层
在典型的 Spring 体系结构中，DAO 是有效的策略模式对象，可以将服务层对象与有关获取和保存持久对象的技术细节分离开。
Spring 支持多种 ORM 工具和持久性框架，包括（但不限于）TopLink、Hibernate、JDO（Java 数据对象）、iBATIS SQL Maps 和 Apache OJB (ObjectRelational Bridge)。
Spring 用一致的方法来使用这些工具，但并不企图完全对 ORM 工具进行抽象化，因为这样做将适得其反。因此，DAO 接口的实现将使用 ORM 工具自带的查询 API：Spring 并不试图创建查询抽象，这是因为该抽象不如主流 ORM 产品功能强大。
Spring 如何利用 ORM
要使 DAO 接口独立于底层持久性技术，我们需要解决一些关键问题。Spring 在此提供了重要的帮助，这在异常处理、资源获取和释放以及事务管理方面表现的尤为显著。
Spring 异常处理：Spring 的异常处理的两个主要特性使它可以独立于底层持久性技术。首先，它使用基于类的普通数据访问异常层次结构（图 4 显示了该层次结构中最重要的类），该层次结构可以利用任何底层 ORM 的异常机制。可以轻松地对该异常层次结构进行扩展。例如，您可以编写服务层代码来处理 DataIntegrityViolationException（违反了类似主键约束这样的约束）而不必考虑所使用的数据访问工具（可能是 JDBC、TopLink、JDO、Hibernate 或其他所支持的框架）。如果您要为数据库或持久性工具所特有的错误条件添加映射，您甚至可以在不修改 Spring 代码的情况下对该层次结构进行扩展。
 |
| 图 4。Spring 的异常类层次结构的 UML 图
|
其次，Spring 的异常处理方法使用未检查的异常。使用未检查的异常尤其适合于与异常层次结构联合使用，这是因为您只需捕获可以恢复的特殊子类。由于仍需要捕获基类，因此捕获已检查异常的子类的用处并不大。（请注意，JDBC 就使用已检查异常而言总有一些独特的 API：例如，TopLink 和 JDO 都使用未检查的异常。在版本 3 中，Hibernate 将从已检查的异常转换为未检查的异常。）
资源获取和释放：使用任何数据访问技术的主要挑战之一是即便在遇到错误的情况下也必须正确获取和释放 JDBC 连接或 ORM 会话等资源。
| （ORM 会话是由 ORM 工具管理的事务性的工作单元。会话包含一组与事务关联的对象，其中的某些对象可能在事务执行过程中已经被修改，而且 ORM 工具针对此修改生成 SQL 以更新数据库。因此，会话管理对数据完整性至关重要。）
|
Spring 通过使用回调方法解决了资源获取和释放问题。框架负责获取和释放资源，而应用程序开发人员则在回调方法中用代码对所需的资源执行必要的持久性操作。这样，应用程序开发人员即可专注于他们应用程序的独特需要而非编写衔接 (plumbing) 代码了。
提供此功能的 Helper 类被称作模板。Spring 在许多存在此类资源获取和释放问题的 API（如 JDBC、JNDI 和 JMS）中提供了一致的方法。
事务管理和线程绑定：Spring 的资源获取与释放策略与其事务管理支持相集成。为同一事务中的每个操作获取同一资源很重要。虽然 JTA 和 JCA 可以在一个完备的 J2EE 环境中为此提供支持（取决于持久性工具），而 Spring 则在任何环境（包括 J2SE 环境）中为此提供支持。此外，必要的 Spring 配置也比 JCA 配置简单。
Spring 通过将资源（如 JDBC 连接、TopLink 或 Hibernate 会话）绑定到当前线程来执行此操作。许多应用程序开发人员已经在他们自己的应用程序中实现了此支持。而 Spring 解决方案不但具有比通常的内部解决方案更完善（支持事务挂起和许多其他实现起来比较复杂的增值服务）的优点，而且消除了编写和维护此类定制代码的需要。而且普通的关心最多产生普通的解决方案。
方便类和方法
Spring 提供了方便类来简化每个受支持的持久性工具的使用。
例如，JDBC、TopLink 和 Hibernate 支持类提供了查询和保存方法，这些方法将此类操作减少为一行代码，如下所示：
使用 Spring HibernateTemplate 方便类的 Hibernate 查询：
List customers = hibernateTemplate.find("from Customer c where c.age > ?", age);
使用 Spring TopLinkTemplate 方便类的 TopLink 查询：
List customers = toplinkTemplate.findByNamedQuery(Customer.class,"findAllCustomersOlderThan",args);
这样的方便方法由于使用持久性工具自带的 API 以及处理资源获取和释放，从而显著减少了应用程序中所需的数据访问代码。
Spring 与 TopLink 配合地非常好。TopLink 是一个复杂的产品，因此由 Spring 提供的一致的体系结构方法和“模板”工具可以为用户提供有用的指导。
|
初现端倪：EJB 3.0 简介
企业 JavaBean (EJB) 3.0 规范（当前通过 JCP 发展为 JSR-220）将包含一个 POJO 持久性规范，该规范将有效防止实体 bean 模型过时。此创新还将导致对象关系映射领域中出现一定程度的不确定性。
然而，如果您的应用程序可以从对象关系映射中获益，则应立即采用 ORM 工具，从而提高生产效率。如果选择一个主流产品（如 Oracle TopLink、Hibernate 或 Kodo JDO），则可以确保供应商将为 JSR-220 POJO 持久性提供一个移植策略 — 您也可以从现在开始的两年时间里使用同一工具，只不过是通过不同的 API 而已。（从 EJB 2.x 实体模型移植到 JSR-220 POJO 持久性将更困难。）
而且，EJB 3.0 规范直到 2006 年初才会发布 — 同时，必须有一个可行的、高效率的对象映射解决方案。
|
一个使用中的持久性例子是：Spring 和 TopLink 集成项目
Spring/TopLink 集成（现在在 OTN 上提供）基于由 Spring 与其他 ORM 框架的集成建立的一致的体系结构模式。Spring-TopLink 集成代码由 Oracle TopLink 小组编写，但很可能由 Oracle 捐赠给 Spring 项目。Oracle 和 Spring 界都计划支持集成用户。
通过 Spring-TopLink 集成，无论您是在应用程序服务器的内部还是外部使用 TopLink，都可以使用一致的编程模型。Spring TopLink 集成包括：
- 方便类（如 TopLink 模板），这些类通过消除资源查找简化了许多 TopLink 操作，并为实现更复杂的操作提供了简化的模型。
- 异常转换实用程序，可以将 TopLink 异常转换为 Spring 的 DataAccessException 层次结构。
- 与 Spring 事务管理的集成。测试应用程序 PetClinic 演示了该集成，并帮助您开始使用 Spring 和 TopLink。尽管 PetClinic 是一个简单的应用程序，但它演示了一些重要的最佳实践，并可以用作一个体系结构模板来应对 Spring 和 TopLink 更复杂的使用情况。
默认情况下，PetClinic 基于 HSQL（HypersonicSQL，一个简单的纯 Java 数据库，用于测试或具有非常简单的数据访问要求的应用程序）运行。但通过在 TopLink 层中进行简单的重新配置，您可以使用 Oracle 或其他功能完善的数据库（下载中提供了有关重新配置 PetClinic 以使用 Oracle 的说明）。
当将 Spring 与 TopLink 一起使用时，请确保：
- 使用命名查询。长期以来，这一直是 TopLink 咨询人士所建议的最佳实践。
- 使用 TopLinkTemplate 类获取并使用 TopLink 会话，而非编写您自己的代码来管理 TopLink 会话。这将节省您的时间和工作量，并可确保应用程序中错误处理的一致性。
- 遵循通常的 Spring 体系结构实践，并将 TopLink 的使用隐藏在 DAO 接口之后。
结论
持久性对于 J2EE 项目的成功至关重要。但愿本文已使您确信 ORM 的价值。如果您的项目能得益于 ORM，则您的生产效率将很有可能获得明显提高。
Spring Framework 是一个应用程序框架，它为 Java/J2EE 应用程序的所有层提供服务。本文主要介绍了 Spring 获得持久性的方法，但实际上这只是 Spring 所提供功能的一部分。Spring 为访问持久性数据的 J2EE 应用程序提供了一致的体系结构。Spring 与所有主流对象映射技术（包括 Oracle TopLink）集成在一起。Oracle 对 Spring-TopLink 集成所做的努力对于 Spring 和 TopLink 解而言都是一个好消息。
如果您是一位 TopLink 用户，您将非常喜欢这为您的编码所带来的简化和一致性。同时，您不必牺牲 TopLink 的任何功能。如果您是一位 Spring 用户，则您现在可以选择 TopLink 来满足您的 ORM 需要。
|
关于 TopLink
TopLink 可能是最成熟的 ORM 框架。它最初是在 1994 年用 Smalltalk 开发的。1997 年之后，它主要就面向 Java 了。如今，TopLink 可以在 J2EE 应用服务器的内部或外部使用。尽管 TopLink 现在由 Oracle 拥有并提供支持，但它可以用于任何主要的数据库，而不只是 Oracle。它可用于所有 J2EE 应用服务器内 — 实际上也可以用在应用服务器的外部。
TopLink 提供了各种 ORM 功能。同所有的好 ORM 工具一样，TopLink 使您能够持久保存 POJO（传统 Java 对象，这些对象对于 TopLink API 的依赖性最小）。TopLink 提供了各种高级映射，包括对继承和 BLOB 类型（包含流）的支持。它还为乐观锁定（如果使用得当可以提高吞吐量）提供了复杂的支持。
值得注意的是，TopLink 不是一个纯 ORM 工具，它还提供了集成的缓存解决方案（包括跨集群的缓存协调）、丰富的查询支持、O-X 功能、多个优化与数据库交互性能的特性（如“间接”）以及事务管理。
Oracle JDeveloper 10g (10.1.3) 开发人员预览版为您提供了单一 IDE，通过它您除了可以编写 Java 代码以外，还可以定义 toplink 映射以及直观构建 JSF 和 JSP 页面。Oracle JDeveloper 集成了 TopLink Mapper，以帮助开发人员使用强大的 TopLink 持久性层来直观地将 Java 对象映射到数据库表。使用 TopLink 作为自定义 Java 类的持久性体系结构的开发人员能够利用 ADF 模型层的通用数据绑定特性来简化构建 JSP、uiXML 和 Swing 应用程序的用户界面。
这些年来，TopLink 已被认可为 Java 系统提供持久性服务的领先者。以下是其他一些 Oracle TopLink 资源：
|
|
关于 Spring
Spring 是一个多层应用程序框架 — 类似于“松散耦合的子框架的框架”。在 Spring 的众多特性中，一些关键服务包含：
- 支持相关性注入的控制倒置 (IoC) 容器（Spring 核心包），它是 Spring 最先引入的一个用于配置基于 POJO 的应用程序的强大技术。Spring 是 IoC 领域众多框架中最受欢迎、最强大的一个。
- 支持将横切功能应用于 POJO 的纯 Java AOP（面向方面的编程）框架（Spring AOP 包），它为各种环境中的事务管理提供了复杂的支持。
- 灵活的 web MVC 框架。Spring 还以随取随用的方式集成流行的 web 层解决方案，如 Struts、WebWork、Tapestry 或 JSF。
- 一个获得持久性的通用方法（Spring DAO 包）。
- 为远程控制、使用 EJB、JMS 和其他重要的企业功能提供支持（Spring Context 包）。
- 与各种第三方产品集成，包括 Quartz 调度程序和 Velocity 模板引擎。
但 Spring 所涉及的领域远非如此。以下是其他一些信息资源：
|
Rod Johnson 是 Interface21（一家专门提供专家级 J2EE 和 Spring Framework 服务的咨询公司）的 CEO。他是一位在保险、互联网和财务领域具有丰富实践经验的企业 Java 架构师。他曾是欧洲最大 Web 门户之一的 J2EE 架构师，并曾担任各种项目的顾问。他以 JSR-154 (Servlet 2.4) 和 JDO 2.0 专家组成员的身份积极参与了 Java Community Process。他是最畅销的“专家级一对一 J2EE 设计和开发”（Wrox 于 2002 年出版）和“无 EJB 的 J2EE”（Wrox 于 2004 年出版）的作者，并从 2000 年起还参与编写了其他几部图书。Rod 是开放源代码界中的一个举足轻重的人物，他是 Spring Framework 开放源代码项目（源自“专家级一对一 J2EE 设计和开发”中提供的代码）的联合创建者。
Jim Clark (james.x.clark@oracle.com) 是 OracleAS 解决方案架构师小组的成员。他专门从事 J2EE/Toplink 开发，当前正负责 Oracle 集成 TopLink 和 Spring 的工作。他当前从事的其他项目包括使用 AOP 技术增强 Object 持久性。
[返回 J2EE 系列主页]
书签
){kind=link}