本文將介紹 Java? Platform, Enterprise Edition (Java EE 5) 的一種設計方法,它利用了 Enterprise JavaBeans? (EJB) 3.0 新的 Java Persistence API (JPA)。JPA 提供了一種標準的對象關系映射解決方案,該解決方案避免了依賴第三方框架(如 Hibernate)。您將看到示例應用程序的詳細內容,其中驗證了本方法并闡明關鍵設計決定。<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
期待已久的下一版本 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") |
清單 2. 使用 @PostConstruct 注入協作者
MessageSource messageSource; |
選擇 bean 實現類的測試策略的主要因素是類完全依賴協作者來提供服務。這意味著類和協作者的交互作用需要被驗證。正如您在 測試 一節看到的,模仿對象方法完全滿足該目標。
數據訪問層被設計為一系列粗粒度的 DAO。DAO 被實現為無狀態會話 bean,一個 bean 對應一個邏輯域:
AccountDao
、
OrderDao
和
ProductDao
。
每個 bean 都要把實體管理器注入到其中:
@PersistenceContext(unitName = "manager1") |
這是應用程序中 持久性調用類(persistence-aware) 最多的層。它廣泛使用全新的 Enterprise JavaBeans Query Language(EJB QL)(參見 參考資料 )。所有持久性相關的行動都在該層發生,例如:
profile = (UserProfile) em.createQuery( |
下面是另一個例子:
em.persist(account); |
事實上這些類是持久性調用類(persistence-aware),需要一種容器內測試策略,這將在 測試 一節進行描述。
您可以把 JPA 看作是眾所周知的透明持久性技術(如 JDO 和 Hibernate)的繼承者。盡管透明持久性可看作一個附加(add-on)服務,可被應用到忽略持久性的 Plain Old Java Objects (POJO)中,但 JPA 還是對域對象施加了少量限制。
首先,您通常要具有一個映射到對應數據庫表主鍵的(代理)對象標識符:
@Id |
其次,在聯機事務過程(OLTP)環境中,需要一個 version 字段或 JavaBean 屬性以進行樂觀并發控制:
@Column(name = "row_version") |
最終,如果您選擇使用注釋方式的映射,映射注釋將分布在代碼周圍。
另一種限制源自于這樣一個事實:域對象可以通過由實體管理器所管理的域對象所在的層訪問,也可以通過分離它的所有其他層訪問。此外,對象可能是新的或已刪除的。一般情況下,對象的行為取決于其持久性狀態。例如,假設在實體管理器中執行以下這行代碼:
int size = attachedProduct.getItems().size(); |
項集合使用給定產品的項填充,
size
變量的值大于 0。如果使用默認懶加載(lazy)配置的一對多關聯,并在表示層中執行同一行代碼,
size
變量的值為 0。 換句話說,在實體管理器之外(在實體管理器內也沒關系)無法把
非活動(lazy)
對象與
活動(eager)
對象區分開。解決此問題的方法是強制執行項目規范和約定。
在域對象中,您可以把相同的推理應用到業務方法。無論是否在實體管理器中,它們都應該準備好在任何層中調用。這就是把域對象中的業務方法數量限制為必要的最少數量的理由。
雖然有上述各種情況,域對象依然保留許多 POJO 特性。這意味著您可以使用 plain old Java test (POJT) 對業務方法進行測試,POJT 這一術語引自 Expert One-on-One J2EE Development without EJB 一書(參見 參考資料 。)
OR 映射是圍繞 JPA 設計的應用程序的重要元素。它直接影響實體管理器填充域對象的方式。因此,變更映射能夠在表示層覺察到。變更獲取類型或級聯類型可能將產生非常不利的影響。
正如前面所述,有兩種定義映射的方法:元數據(注釋)和映射文件。盡管我們高度提倡采用元數據的方法,但您應該也注意到了它所帶來的不便。從本質上 講,此方法牽涉應用程序的兩個邏輯層:域模型和映射信息。因為這兩個層是分散的,所以這兩個層需要使用不同技術進行單獨測試。元數據方法本身不會影響層的 可測試性。更確切的說,元數據方法使這兩個層好像只是一個層,由于受一系列因素的影響,這可能會引起問題。
影響映射方法選擇的一個因素是項目小組結構。在只有少數開發人員參與的小型項目中,表的數量很少(一般說來少于 100 個表)而且沒有專職的映射人員,因為通常使用注釋會更加快速,所以把注釋方法看作定義映射也許是最佳選擇。對于擁有專職映射人員或映射小組的中型和大型項 目來講,使用映射文件的方法才是更好的選擇。該方法可以降低資源爭用并使開發過程具有另一種自由度。基于元數據的映射方法證實是 PetStore 應用程序更加節省時間的方法。
OR 映射層的目的是使其余應用程序免受底層數據庫變更的影響。當把 PetStore 應用程序后端遷移到 PostgreSQL 時,無需對映射層作出任何變更。這可能要歸結于這一事實:原始數據庫和 PostgreSQL 這兩者均支持序列,因此主鍵生成策略保持完好。一般情況下,您應該對與對象 ID 處理相關的映射區域進行重寫。
對映射的全面測試覆蓋極為重要。必須覆蓋所有關系映射以確保對獲取行為和過渡持久性進行測試。您能夠利用容器外使用的 JPA 來執行該任務(將在下一節進行詳細介紹)。
![]() |
服務層設計的關鍵要素是,關注與底層的協作以提供請求的服務。這需要考慮到使用動態模仿對象的可靠測試策略。我使用 EasyMock 框架(參見 參考資料 )來實現測試方法。
DAO 層具有強大的數據庫內聚力。這就是可靠測試需要某類容器內策略和數據庫訪問的原因。盡管這對于遠程 EJB 很容易,還是需要考慮適合本地 bean 的有意義的方法。此處令人困擾的因素是:
- 需要容器內測試 facade
- 域對象是非連續的,所以全部驗證需要發生在容器內。
JBoss Embeddable EJB3 容器(參見 參考資料 ) (撰寫這篇文章時尚處于測試版階段)被證實是更適當的選擇。因為能夠從單元測試啟動 JBoss Embeddable EJB3 容器,這樣所有代碼都運行在同一 JVM 中。使用可嵌入容器的容器內測試可實現它的目標,但過程比較緩慢,因為容器啟動時間就需要大概 30 秒。這種問題可能是由較早的產品狀態造成的,可通過合理的配置改進。
我采用 POJT 對域模型類的業務方法進行測試。不需要其他測試技術,況且其他測試技術不適合這些類。
OR 映射是一個需要窮舉測試覆蓋的主要層。該層對數據庫非常敏感,所以該層不能應用模仿對象或 POJT 技術。但是,您可以利用 JPA 的容器外功能。我就使用這種策略來測試 PetStore 或 OR 映射層。
您需要牢記測試中的測試關聯和過渡持久性行為的重要性。這樣您才能及早注意到獲取類型的變更或級聯類型值的變更,并采取適當的措施。
PetStore 應用程序設計的關鍵特性是它的本地特性。使應用程序的所有邏輯層運行在同一 JVM 中,這種方法具有很多優點。有關該主題的詳細討論,請參閱 Expert One-on-One J2EE Development without EJB (參見 參考資料 )。
不過,應當說明的是:通過 遠程處理 facade ,您可以輕松向應用程序添加遠程處理功能。遠程處理 facade(而不是我在前面描述的服務 facade)公開了一個遠程界面,它具有兩個職責:進行域模型和順序數據傳輸對象(DTO)(參見 參考資料 )之間的相互轉換和在服務 facade 上調用適當的方法。
使用遠程無狀態會話 bean 能夠實現本應用程序。唯一障礙是創建其他 DTO 層和進行它們與域模型之間相互轉換。然而您需要它來確保實現整潔的界面以及與遠程客戶機的松散耦合。
EJB 3.0 和 JPA 毫無疑問將是 Java EE 5 的主要賣點。在某些領域中,它們給正常的 Java 社區帶來競爭優勢,并使 Java 在其他領域與競爭對手不分伯仲。(不可否認的是,目前某些領域尚不存在基于標準的方法。)
過去數年來,Spring Framework(參見 參考資料 )一直是 EJB 在企業領域的主要競爭對手。EJB 3.0 規范解決了很多促進 Spring 興起的問題。隨著它的出現,EJB 3.0 毫無疑問比 Spring 提供了更好的開發體驗 -- 最引人注目的優勢是它不需要配置文件。
JPA 提供一種標準的 OR 映射解決方案,該解決方案完全集成到 EJB 3.0 兼容的容器中。JPA 的前輩將會繼續穩定發展,但是業務應用程序中的 raw 使用將可能會減少。實現 JPA 兼容的實體管理器似乎很可能是此類技術的發展方向。
在撰寫本文時,EJB 3.0 規范還處在建議的最終草案(Proposed Final Draft)階段(參見 參考資料 )。以下是一些未解決的問題以及與 JPA 相關的預實現:
-
? 當前形式的 JPA 規范沒有定義只讀實體 bean。這讓人困惑,因為兼容 EJB 2.1 規范的實體 bean 支持這種特性。Spring 框架也支持只讀事務。
-
? 可插入的持久性提供者概念仍處于未交付的階段。
- ? 標準樂觀并發異常 -- OptimisticLockException -- 首次出現在 EJB 3.0 Proposed Final Draft 中。在持久性提供者執行它以前 ,您還需要使用特定于提供者的異常,如 Hibernate 的 StaleObjectStateException,來檢測樂觀并發問題。暫時,這種情況限制您的實現只能采用特定的持久性提供者。
Java EE 系列規范的較大問題與 JPA 沒有任何關系。Java EE 系列規范的問題涉及到 Web 和 EJB 容器之間的集成。Spring 在此領域仍然具有主要競爭優勢。JBoss 的 Seam 項目(參見
參考資料
)嘗試使用自定義的方法來解決這一問題。Caucho Resin 應用服務器(參見
參考資料
)試圖擴展容器邊界并支持在 Web 容器中使用
@EJB
注釋。我們希望 Java EE 5.1 將解決層集成的問題,為我們提供一個全面而標準的依賴性注入方法。
描述 名字 大小 下載方法 PetStore
j-ejb3jpapetstore.zip | 149KB | HTTP |
![]() |
||
![]() |
關于下載方法的信息 |
![]() |
學習
-
您可以參閱本文在 developerWorks 全球站點上的
英文原文
。
-
JSR 220: Enterprise JavaBeans 3.0
和
EJB 3.0 Proposed Final Draft
:在 Java Community Process 網站上查看最新的 EJB 3.0 及 JPA 規范。
-
Rod Johnson 和 Juergen Hoeller 所著的
Expert One-on-One J2EE Development without EJB
(Wrox,2004 年):了解 EJB 替代方法和 Spring Framework。
-
"
EJB 倡導者: EJB 2.x 過時了嗎?
(Geoff Hambrick,developerWorks,2006 年 2 月):這篇文章探討了 EJB 3.0 規范的一些新特性(包括 JPA)。
-
JBoss EJB 3.0 Project
:閱讀 JBoss 的 EJB 3.0 實現。
-
Hibernate
:Hibernate 是一種開放源碼透明持久性框架。
-
Data Access Object
:閱讀 Data Access Object (DAO) 設計模式。
-
Core J2EE Patterns - Transfer Object
:閱讀 Transfer Object 設計模式。
-
Spring Framework
:Spring 是 EJB 的主要競爭對手。
-
JBoss Seam
:JBoss Seam 是 Java EE 5 的應用程序框架。
-
Resin
:開放源碼應用服務器中的 Resin。
-
Java 技術專區
有數百篇關于 Java 編程各個方面的文章。
獲得產品和技術
-
Java Platform, Enterprise Edition (Java EE) 5
:下載預覽版。
-
EasyMock
:使用 EasyMock 庫對您的代碼和動態模仿對象方法進行測試。
- JBoss Embeddable EJB3 :在“容器外”測試容器內代碼。
![]() |
||
![]() |
Borys Burnayev 是一名具有超過 12 年從業經驗的軟件開發人員,過去 5 年中,他從事 Java 及相關技術的工作,最近開始專注于 J2EE 設計問題與對象關系技術。Borys 擁有應用數學的碩士學位。他還擁有 Sun Certified Architect 技術認證和 Sun、Oracle 、IBM 多家公司的其他技術認證。 |
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
