對於開發新軟件系統來說，面向對象編程無疑是當今使用最為廣泛的編程模式。由於商業數據的持久性需求，關系數據庫管理系統（RDBMS）取得了最為廣泛的應用。RDBMS 使用的是關系模型，它與軟件系統中的域對象模型有所不同。使用面向對象編程語言開發軟件系統並使用 RDBMS 來持久存儲數據時，數據持久化框架將成為應用程序架構中非常關鍵和重要的組件，它們的作用是隱藏應用程序數據持久化的底層復雜性。
在過去的幾年中，一些持久化框架得到了很好的發展，它們可幫助您管理對象關系映射和數據持久性需求。但是，根據需要選擇一個合適的框架並不是一件簡單的任務，因為多種因素會影響到這個決定。在本文中，我將根據三個基本標准來討論如何一些應用比較廣泛的 Java 持久化框架中做出選擇：選擇、時機和優缺點。在“選擇”這部分中，我將介紹如何選擇框架；在“時機”這部分中，我將討論一些您應該考慮應用框架的應用場景以及一些您應該尋找備選方案的應用場景；最後，在“優缺點”這一部分中，我將討論當您決定采用某個框架時，該框架所有的優勢和缺點。首先要討論的是下面這個在 Java 持久化領域中最著名的框架。
Entity Enterprise Java Bean
Java Persistence API
Hibernate
TopLink
讓我們更加詳細地討論這些框架。
Entity Enterprise Java Bean
Enterprise JavaBean（EJB） 技術是針對 Java 平台 Enterprise Edition (Java EE) 的一種托管的服務器端組件架構。在此定義中，“托管”和“服務器端”是關鍵術語。在 EJB 架構中，應用服務器 將管理一個或多個已部署的 EJB 的生命周期，並通過 EJB 容器提供公共運行時服務。容器提供的服務包括安全性、並發控制、事務和持久化管理等。
EJB 規范 定義了三種 Enterprise Bean 類型：Session、Entity 和 Message Driven。每種類型都具有一些獨特特性，分別用於不同目的。由於本文是關於 Java 持久化框架的，我們將簡單討論一下 EJB 架構的持久化方面，討論中會涉及使用 Entity EJB 管理您的 Enterprise Java 應用程序的持久化要求。
使用 EJB 設計應用程序時，EJB 表示業務域模型中的一個實體。例如，試想一個商業銀行應用程序的 Account 實體。該 Account Entity Bean 將被部署到 J2EE 應用程序服務器中，該服務器將通過 EJB 容器給此 Entity Bean 提供一些運行時間服務。這種服務是自動持久化的，我將更加詳細地討論。
根據持久化實現的方式，Entity EJB 可以進一步劃分為兩種：Bean-Managed Persistence（BMP）和 Container-Managed Persistence（CMP）。使用 BMP，Bean 實例通過 JDBC 代碼負責其狀態的持久化。而使用 Container-Managed Persistence，EJB 容器提供自動管理 Entity Bean 的持久化的能力：當需要時，將狀態保存到底層數據庫或從底層數據庫加載狀態。
現在讓我們討論一些應用場景，在這些應用場景中您一般可能想要應用 EJB 框架，特別情況下可能使用 CMP 進行數據持久化。
何時考慮將 EJB 作為持久化框架
首先您要考慮的是需要容器提供的服務。如果您的應用程序需要除持久化管理以外的其他容器提供的服務，比如轉換管理、安全性和並發控制，則最好使用 EJB 框架。
另外還要考慮資源要求。EJB 框架可為需求應用程序提供完美的可伸縮性。但是，這也是有代價的：密集的資源要求，尤其使用 遠程接口 模式時。只在沒有資源限制的時候考慮應用 Entity EJB，以便獲得所需的性能水平。
還有一個相關的因素是 de facto 框架。如果您正在進行某個基於 Java 平台的 EE 部署，則機會在於 EJB 容器已成為您的應用程序服務器的一部分。“為什麼不用已經可用的？”可能是在你的架構決策制定過程中首先要問的問題。我把這看作是相對其他框架的一個“政治”優勢，因為它已經可用了。
何時考慮將 EJB 的備選方案作為持久化框架
持久層的功能要求可能是提示您需求備選方案的第一個因素。如果您的應用程序不需要 EJB 框架提供的每個功能，則這表示您應該尋求一個備選方案。
資源可用性超過了性能要求可能是另一個您想要尋求其他備選方案的情況。盡管 EJB 框架提供了完美的性能和可伸縮性，但是 EJB 框架的對資源的消耗也是非常驚人的。底線問題是：我們真的需要這個嗎？ 在很多情況下，寫得很好的數據訪問對象或 Hibernate 框架就可提供完美的備選方案。
盡管很少，但數據源（而不是關系數據庫）可能阻止您使用容器管理的持久化框架。
如果您已經使用或計劃使用 EJB 作為您的持久化框架，這裡是一些您可以預期的優勢和缺點。
Entity EJB 有什麼優勢？
該基於組件的分布式模型使其獨立於網絡 - EJB 組件可以部署到為其他應用程序提供服務的同一 JVM 上，或者位於不同地理位置的應用程序服務器的 JVM 上。
您將獲得完美的可伸縮性：EJB 可以很好地向上擴展，因為容器可以匯聚實例，必要時可以進行激活和鈍化。
EJB 經過長時間的檢驗，已成為成熟的技術。而且，它經過發展，還可以提供更多有用的服務和功能。例如，計時器服務就是我最喜歡的服務之一；使用它，您可以計劃作業按指定的間隔執行（比如每晚、每周或每月）。在 EJB 3.0 中還有一項有用的功能“Java 語言元數據注釋支持”，該功能消除了實體持久化所需的所有接口以及在 EJB 的查詢語言中的增強。
Entity EJB 有什麼缺點？
學習和使用 EJB 架構是不簡單的。您應該准備學習一些術語，比如 remote interface（遠程接口）、home interface（Home 接口）, activation（激活）、passivation（鈍化） 等等，其中大部分僅適用於 EJB 世界。
EJB 架構不提供持久化獨立。由於這些類在 EJB 容器中以其自己的方式使用，因此沒有在其他框架中使用 EJB 類的簡便方法。
對於 Entity Bean，要想獲得可接受的性能水平一直是一個挑戰，尤其是在遠程接口模式中。
Java Persistence API
從 EJB 技術可以開始應用時起，對其在實際應用中的可用性就一直存在懷疑。在我看來，產生這種現象最重要的兩個原因是復雜性和資源密集性。結果，隨後出現了比 EJB 更簡單、具有更小資源空間的框架（比如 Spring 和 Hibernate），並且更快流行開來。為了說明這一點，我們注意到 EJB 3.0 規范的方向相對以前出現了一個主要的轉變。作為 JSR 220 的一部分，該規范提供了類似 Plain Old Java Object (POJO) 支持、Dependency Injection（依賴注入）和注釋等功能。現在引入了一組全新的 API：Java Persistence API (JPA)，以允許開發者管理 Java EE（甚至 SE）應用程序中的關系數據。另外，Sun 聲稱 Java Persistence API 表現了一些 Hibernate、TopLink（二者都會在稍後討論）、JDO 以及 EJB 框架中最好的想法。
當前，GlassFish 項目提供了實施 JPA 的一個參考，JPA 在 GlassFish 應用程序服務器中作為 TopLink Essential 部分。您可以在 GlassFish 社區頁 找到該 JPA 參考實施。不要混淆 TopLink Essentials 和 TopLink，前者現在是由 Oracle Corporation 擁有的關系映射工具。稍後我將在本文中討論 TopLink 框架。
讓我們來討論一些您應該考慮應用 JPA 作為持久化框架的應用場景。
何時考慮將 JPA 作為持久化框架
您選擇從流行的框架（比如 Hibernate、TopLink 和 EJB）中選擇應用具有“好用”的功能且基於標准的框架。
您需要輕量級的持久化框架，且不需要 EJB 的容器提供的服務。
您需要可以在標准或 Enterprise Java 應用程序中使用的持久化框架。
何時考慮 JPA 的備選方案
您使用的 Java 的版本決定了實際是否可以應用 JPA。JPA 是 EJB 3.0 規范的一部分，而該規范是 Java EE 5 版本的一部分。如果您未更新到 Java EE 5，則無法使用 JPA。
您的應用程序需要 JPA 無法提供的服務，比如那些由 EJB 容器提供的服務，在那些情況下您更依賴 EJB。
在結束對此框架的討論前，讓我們列出一些使用 JPA 作為持久化框架的優勢和缺點。
JPA 有什麼優勢？
JPA 是基於標准的。越來越多的提供商期待在不久的將來提供 JPA 實施。
它提供了 Hibernate 和 TopLink 中最好的功能。
它可以和 Java SE 和 Java EE 應用程序一起使用，需要使用 EJB 容器，也可以不要。
JPA 有什麼缺點？
由於非常新，JPA 規范可能還需要進過重要發展才會變得很穩定。
JPA 是一個規范而不是一個產品。您需要提供商提供一個實施，才能獲得這些基於標准的 API 的優勢。
Hibernate
Hibernate 是一個對象持久化框架，簡化了 Java 應用程序和底層關系數據庫之間的對象關系映射。方法是提供 POJO 的透明持久化，作為“中介”層來提供自動持久化，並從 Java 應用程序加載對象到數據庫表。借助 Hibernate，保存對象狀態到數據庫和從數據庫加載對象狀態與調用 Java 對象中的方法一樣容易。您無需從您的應用程序代碼中管理底層的數據操作；Hibernate 框架會為您完成所有的中間步驟。
讓我們討論一些您將會考慮應用 Hibernate 作為持久化框架的應用場景，以及那些您將尋求備選方案的應用場景。
何時使用 Hibernate 作為持久化框架
您正在尋求一個簡單的持久化框架，該框架容易學習和使用。在您能夠實際開始持久化您的 Java 對象到目標數據庫之前，您只需要了解幾個映射配置文件。
您正在尋求一個非常普通和靈活的持久化框架。Hibernate 的用法非常靈活：無論是否有應用程序服務器都可以使用，無論是否有關系數據庫系統也可以使用。
您不想支付獲取和維護費用。Hibernate 是開源而且免費的。
Hibernate 框架非常值得應用，因為它非常簡單和靈活，同時也很強大。但是，在以下一些應用場景中您可能想要考慮應用其他框架。
何時考慮 Hibernate 的備選框架
您還不想要其他框架。盡管簡單，Hibernate 框架仍然有自己的學習曲線、維護/更新周期，等等。
您需要容器提供的服務，比如那些由 EJB 提供的服務，在那些情況下您的選擇局限於 EJB。
如果您正在使用或計劃使用 Hibernate 作為您的持久化框架，這裡是一些它的優勢和缺點。
Hibernate 有什麼優勢？
Hibernate 易於學習和使用。正如我在上面提到的，在您可以使用它之前，您只需要了解幾個簡單、自我描述的配置文件。
它非常靈活。您可以在任何需要持久化服務的應用程序架構中使用 Hibernate。您可以通過 Servlet 和/或 Enterprise Java Bean 在 Standard Java 應用程序、Enterprise Java 應用程序中使用它。它也可以和 Spring 框架很好地集成。
它可以很好地向上擴展，因為它被設計為從底層一直到集群環境中工作。通過類似 Lazy Initialization 的技術以及通過 CGLIB 運行時間字節代碼生成庫優化 Java 反射，最新版的 Hibernate 的性能也得到了加強。
Hibernate 有什麼缺點？
Hibernate 是另一個擁有自己的應用和維護周期的框架。
盡管有積極的社區支持，但是有時候缺乏專注於此產品的提供商也使得宣傳應用此框架顯得沒有說服力。
TopLink
TopLink 是 Java 的另一個對象關系映射框架，為存儲 Java 對象到數據庫和 XML 文檔以及從數據庫和 XML 文檔加載對象提供了強大而且靈活的框架。進過幾次合並和收購（請參閱 TopLink 的 Wikipedia 頁 中的歷史簡介）, 從 2002 年開始 TopLink 已成為 Oracle Fusion 中間件的一部分。
在 2006 年，Oracle 將 TopLink 產品和開發資源中的源代碼捐獻到了 java.net GlassFish 項目中。該產品名為 TopLink Essentials，並成為 Java EE EJB 3.0 JPA 的參考實施。它是 Oracle 的 TopLink 產品的向下擴展的版本，去掉了一些功能，比如集群的應用程序之間的緩存同步、緩存驗證策略和查詢緩存。同樣在 2007 年，Oracle 將 TopLink 產品和開發資源中的源代碼捐獻到了開源的 EclipseLink 項目中。
這裡是一些你可能想要應用 TopLink 作為持久化框架的應用場景，以及一些您想要尋找備選方案的應用場景。
何時使用 TopLink 作為持久化框架
盡管 TopLink 可以適應和其他軟件系統一起工作，但是如果您的軟件系統使用 Oracle 軟件產品的話會更好，因為這樣可以構建一個來自同一提供商的同質軟件產品套件。
何時考慮 TopLink 的備選方案作為持久化框架
您是一個非 Oracle 商店。如果您只有很少 Oracle 的軟件，則您可以有更多適合您的需求的選擇。這對於基於 EE 的應用程序服務器可能非常典型，因為在寫作此文的同時，以市場份額而論 WebSphere、JBoss 和 WebLogic 是前三名領導的應用程序服務器提供商。
最後讓我們評價一下應用 TopLink 作為持久化框架的優勢和缺點。
TopLink 有什麼優勢？
如果您選擇的軟件隊列中已經有大量 Oracle 產品，則 TopLink 是最理想的持久化框架選擇。
它是由 Oracle 支持的一個非常成熟的框架，而且經過了時間的檢測。
它擁有的高級功能，比如集群的應用程序之間的緩存同步、緩存驗證策略和查詢緩存，使其非常適合在需要高性能且集群的應用程序中應用。
TopLink 有什麼缺點？
它是私有的；其未來的方向由 Oracle 決定。
像使用任何新框架一樣，它也有自己的學習曲線。
持久化框架選擇列表
在繼續討論之前，讓我在下表中總結一下以上討論的框架。在該表中您將看到一般環境（時機）、您應該考慮的框架（選擇）以及您獲得的優勢和缺點（優缺點）。您應該把這些看作是選擇持久化框架過程的起點。您的最終選擇應該基於這些和其他應用程序特定的要求（如果有）。
選擇？（考慮應用）
時機？（您的應用程序是否需要）
有什麼優勢？（您將獲得這些優勢）
有什麼缺點？（您將獲得這些缺點）
Java Persistence API 用於 Standard 或 Enterprise Java 應用程序的簡單持久化框架 它是基於標准的。它結合了許多其他框架中“容易獲得”的功能。
它是一個規范：需要使用特定供應商的實現。不能在 Java 5.0 之前的版本中使用。
容器管理的 Entity EJB 容器提供的服務，比如安全和轉換管理，以及持久化管理。 基於分布式的組件良好的可伸縮性
資源密集學習和使用非常復雜
靈活性較差
Hibernate 您想要一個簡單、靈活的框架 無需獲取和維護費用與其他框架良好集成
學習和使用非常簡單
靈活：有無 EJB 均可使用，可以在 Standard 或 Enterprise Java 中使用
開源 TopLink 您的軟件系統已經使用了大量 Oracle 產品 成熟的技術 特定於供應商其他持久化框架
在結束之前，我列出了其他一些持久化框架。在實際應用某個框架之前，這些框架也是值得探索的。本文不會詳細討論這些框架。
Castor：免費的開源數據綁定框架。
Kodo：BEA Systems 的對象關系持久化引擎。
Torque：針對 Java 平台的對象關系映射器，作為 Apache DB 項目開發。
iBatis：可以同時和 Java 和 .NET 應用程序一起使用的數據映射器框架。
結束語
很明顯，您將為下一個 Java 應用程序應用哪個持久化框架將受很多因素的影響，比如所需的功能、獲得和維護成本以及非功能性的要求（它的可維護性、性能等等）。一些私有和開源的框架現在都已可用，每種都有自己的優勢（好處）和缺點（不足）。
在本文中，我根據三個標准對一些流行的 Java 持久化框架進行了說明：應用哪一個（定義框架）、何時應用（何時應該考慮應用以及何時應該尋求備選方案）以及有什麼（優勢和缺點）。本文中說明的應用場景用於幫助您在實際選擇應用的框架之前，基於更多信息做出正確的決策。因此，您應該基於本文中討論的標准以及其他特定於此應用程序的當前和未來的需求，應用您的下一個 Java 持久化框架。
