使用 EJB 3.0 Java Persistence API 设计企业应用程序

本文将介绍 java™ Platform, EnterPRise Edition (Java EE 5) 的一种设计方法，它利用了 Enterprise JavaBeans™ (EJB) 3.0 新的 Java Persistence API (JPA)。JPA 提供了一种标准的对象关系映射解决方案，该解决方案避免了依靠第三方框架（如 Hibernate）。您将看到示例应用程序的具体内容，其中验证了本方法并阐明要害设计决定。

期待已久的下一版本 Java EE 5 即将发布（参见 参考资料 获得规范和预览版的链接）。Java EE 5 许多新功能都包含经过修补的 EJB 架构，其突出特性之一是 JPA。由于具有容器内和容器外持久性选项，JPA 为 J2EE 架构师带来一系列全新设计选择。本文将着重介绍容器内应用程序的设计，此类应用程序依靠 EJB 容器提供企业服务，如事务处理和安全性。

我将使用您熟悉的 PetStore 应用程序进行测试，以证实 JPA 的功能以及它如何向传统 J2EE 设计模式发起挑战。本应用程序比较琐碎，所以不提供详尽的实现细节。我将用代码摘录对设计注重事项进行说明（完整开放源码的连接请参见 下载 ）。本文假设您熟悉 EJB 3.0 基本概念和对象关系（OR）映射基本概念。（若需了解这两个主题的更多信息，请参阅 参考资料 ）。

设计概述

示例 PetStore 应用程序是基于 Web 的电子交易应用程序，它实现以下用例：

• 浏览产品
• 查找产品
• 维护账户
• 维护购物车
• 创建订单

本应用程序被设计为具有三个主要逻辑层的多层 Java EE 应用程序：

• 表示层（并非本文的重点）使用 Struts 框架。
  
  
• 服务层是一种简单的服务 facade，将所有工作委托给其协作者。服务层的目的是分离服务供给与服务实现。
  
  
• 数据访问层是一系列作为无状态会话 bean 实现的粗粒度 Data access Objects （DAO）（参见 参考资料）。出于持久性的需要，它们都依靠 Java 持久性实体治理器。

应用程序域模型由 EJB 3.0 实体 bean 表示并用于层间的通信。当域对象离开数据访问层时，它与实体治理器脱离。当重新进入数据访问层时，它需要重新连接到实体治理器。

注释似乎是 Java 5 的一个广泛采用的特性，JPA 也不例外。注释可用于指定 OR 映射 —— 在 dW 文档和教程中您经常可以看到 —— 而 PetStore 应用程序出于相同目的使用它们。然而值得一提的是您还能通过映射文件的方式指定 OR 映射。本文稍后的 OR 映射 一节将探讨并比较这两种可选方式。

我在 Jboss 应用服务器中开发并部署 PetStore 应用程序（参见 参考资料）。我使用商用数据库完成大多数开发工作并将应用程序后端移植到 PostgreSQL 数据库（OR 映射 一节包含了关于使用 JPA 时您应该了解的数据库迁移的潜在影响的讨论）。

本案例分析的目的之一是符合设计标准，答应高度可测试的实现。如 测试 一节所见，您能够使用一系列测试技术来测试 PetStore 应用程序。

PetStore 应用程序充分利用了这一事实：它是规则的 Web 应用程序。主要优点是所有层能够运行在相同的 JVM 中，免除了组件分发的需要。本文的 远程处理 一节简要介绍了为应用程序添加远程处理功能的方法。

服务层

服务层被设计为服务 facade。它由 PetStoreService 这一无状态会话 bean 实现。Bean 要完全依靠其协作者来提供 Web 服务。

因为简化的 PetStore 要求被限定于从数据库检索数据并把数据存储于数据库，惟一的协作者就是 DAO。真正的应用程序能够调用 Web 服务，通过 RMI/IIOP 或资源适配器访问其他应用程序，并生成电子邮件消息等。所有此类型的功能都需要其他协作者支持。