利用EJB 3.0的JPA设计企业应用程序

　　本文将介绍 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 或资源适配器访问其他应用程序，并生成电子邮件消息等。所有此类型的功能都需要其他协作者支持。

　　可通过 @EJB 或 @Resource 注释注入协作者（如清单 1 所示）或通过 @PostConstruct 方法注入协作者（如清单 2 所示）：

　　清单 1. 使用 @EJB 注入协作者

 

@EJB(beanName = "AccountDao") 

AccountDao accountDao;

　　清单 2. 使用 @PostConstruct 注入协作者

 

MessageSource messageSource; 

@PostConstruct 

public void init() { 

   messageSource = new MessageSourceImpl("exceptions"); 

} 

　　选择 bean 实现类的测试策略的主要因素是类完全依赖协作者来提供服务。这意味着类和协作者的交互作用需要被验证。正如您在 测试 一节看到的，模仿对象方法完全满足该目标。

　　数据访问层

　　数据访问层被设计为一系列粗粒度的 DAO。DAO 被实现为无状态会话 bean，一个 bean 对应一个逻辑域：AccountDao、OrderDao 和 ProductDao。

　　每个 bean 都要把实体管理器注入到其中：

 

@PersistenceContext(unitName = "manager1") 

protected EntityManager em; 

　　这是应用程序中 持久性调用类（persistence-aware） 最多的层。它广泛使用全新的 Enterprise JavaBeans Query Language（EJB QL）。所有持久性相关的行动都在该层发生，例如：

 

profile = (UserProfile) em.createQuery( 

   "from UserProfile up where up.login = :login").setParameter( 

   "login", login).getSingleResult(); 

　　下面是另一个例子：

 

em.persist(account); 

　　事实上这些类是持久性调用类（persistence-aware），需要一种容器内测试策略，这将在 测试 一节进行描述。

　　域模型

　　您可以把 JPA 看作是众所周知的透明持久性技术（如 JDO 和 Hibernate）的继承者。尽管透明持久性可看作一个附加（add-on）服务，可被应用到忽略持久性的 Plain Old Java Objects (POJO)中，但 JPA 还是对域对象施加了少量限制。

　　首先，您通常要具有一个映射到对应数据库表主键的（代理）对象标识符：

@Id 

@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "AccountSeq") 

@Column(name = "account_sysid") 

public Integer getAccountId() { 

   return this.accountId; 

} 

　　其次，在联机事务过程（OLTP）环境中，需要一个 version 字段或 JavaBean 属性以进行乐观并发控制：

@Column(name = "row_version") 

@Version 

public int getVersion() { 

   return version; 

} 


			   
			   

                       标签：
                   
                   
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com

特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有