利用EJB 3.0的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 提供了更好的開發體驗 -- 最引人注目的優勢是它不需要配置文件。