數據持久性是企業開發中最棘手的一個方面。一個企業數據持久性解決方案必須提供迅速的客戶機事務，隨著時間的過去確保數據完整性，以及在如系統崩潰和網絡故障之類的日常災禍發生時使數據繼續存在。在 J2EE 探險者系列接下來的兩個部分中，我們將著重討論 J2EE 技術，這些技術有助於您為企業體系結構創建可靠的數據持久性解決方案。我們將通過簡要地介紹企業應用程序中的數據持久性來開始該主題，然後繼續更詳細地討論各種技術選項。在本部分中，我們將比較實體 bean 的一站式（single-stop）解決方案同更復雜的（但更健壯的）會話 bean 與 Java 數據庫連接（Java Database Connectivity，JDBC）代碼的組合。在下一部分中，我們將比較 Java 數據對象（Java Data Object，JDO）與實體 bean。
什麼是數據持久性？
數據是任何計算機應用程序最重要的方面。計算機應用程序的核心是使某人或另一個計算機系統能夠訪問其數據。在企業環境中，數據不僅必須是可訪問的（即，與用戶界面連接並按一系列業務規則管理），而且還必須是持久的。 持久數據存儲就是即使在服務器崩潰的情況下仍能存在的數據存儲。
持久數據存在於應用程序的活動內存之外，通常在數據庫或平面文件系統中。雖然持久數據被讀入瞬時存儲器以供使用或修改，但它始終被寫到外部數據存儲中以長期存儲。美國國家標准與技術研究所（The United States National Institute of Standards and Technology）（請參閱 參考資料）定義了三種級別的持久數據：
部分持久數據是一種僅允許對最新版本更新的持久數據結構。
持久數據是一種保留其舊版本的數據結構；即，以前版本和當前版本都可能被查詢。
完全持久數據是一種維護其數據的所有版本並允許對這些版本更新的持久數據結構。
大多數業務應用程序至少提供部分持久數據。這種類型的持久性在事務中期或者甚至在請求中期出現系統故障時容易遭破壞，這會導致數據不完整且常常遭毀壞。另一方面，在持久數據實現中，對系統中斷或故障以“回滾（rollback）”回應，數據狀態被回滾到上一個已知的良好配置。持久數據實現在企業體系結構和數據庫管理系統（DBMS）中很常見。完全持久數據實現非常少見。完全持久數據實現的少數幾個示例有：日志記錄文件系統、VMS 文件系統（如 VAX 和 Mac OS X）以及並發版本控制系統（CVS）。
J2EE 中的持久性
信息時代非常強調分布式企業計算平台的使用。在這類平台上，必須不惜任何代價保護數據並使其永遠持續存在，即使面臨網絡故障、內存洩漏和服務器崩潰時，也是如此。為了維護這種持久性，應用程序組件必須能夠處理並發性、連接管理、數據完整性和同步。J2EE 的所有三種數據管理技術都為開發人員處理這些功能，但每種技術在處理時略有不同。
實體 bean，它提供健壯的數據持久性。bean 容器處理大部分的數據完整性、資源管理和並發性功能，從而使開發人員關注業務邏輯和數據處理，而不是這些低級細節。使用 bean 管理的持久性（Bean Managed Persistence，BMP）實體 bean 時，開發人員編寫持久性代碼而容器確定何時執行該代碼。使用容器管理的持久性（Container Managed Persistence，CMP）實體 bean 時，容器生成持久性代碼並管理持久性邏輯。
JDBC，當與會話 bean 結合時，它可提供簡便的 EJB 開發和與平台無關的部署，而沒有象 EJB 技術那樣的資源使用和內存開銷。象 BMP 實體 bean 一樣，該解決方案要求開發人員編寫持久性代碼。與 BMP bean 不同的是，它還要求開發人員編寫持久性邏輯。因而，開發人員負責確定何時將數據持久保留在數據存儲中以及何時從數據存儲裝入數據。
Java 數據對象是最新的持久性機制。JDO 提供了面向對象的持久數據存儲。開發人員使用 POJO（無格式普通 Java 對象，plain ordinary Java object）來裝入和存儲持久數據。
我們將在余下的文章中討論實體 bean vs. 會話 bean 和 JDBC 組合的優缺點。
實體 bean 的優點
談到企業級數據持久性時，實體 bean 有下列優點：
標准化。EJB 規范定義一組與供應商無關的接口，J2EE 供應商可以實現這些接口來支持實體 bean。這種標准化允許采用最佳實踐的開發並縮短雇用新開發人員時的適應期。因為基本的組件體系結構和設計模式大家都知道，所以很容易找到合格的人才來實現它們。
容器管理的服務。正如我們在本系列的前兩篇文章中討論的那樣，EJB 容器管理的服務為處理諸如安全性、事務處理、連接合用和資源管理之類的企業功能提供了極大的好處。
透明持久性。容器管理的服務思想在 CMP 實體 bean 中得到了進一步加強。這裡，容器還自動管理持久性語義。使用 BMP 實體 bean 時，開發人員必須編寫持久性邏輯，而容器則確定何時調用由開發人員定義的方法。同時使用 CMP 和 BMP 實體 bean 時，容器決定何時持續保持 bean 的狀態以及如何確保與底層數據存儲的數據完整性和並發性。
事務支持。開發人員對 CMP 事務（隔離級別、事務需求和方法的包含／排除）有粗粒度的控制權，對 BMP 事務有細粒度的控制權，這些控制都是通過在 bean 代碼中以程序方式處理事務語義實現的。在這兩種情況下，容器管理事務並確定是否應該提交給定的事務。
基於組件的設計。實體 bean 被設計成自包含組件，這些組件配置有部署描述符，無需更改任何代碼就可以將它們部署到任何 J2EE 應用程序服務器。
總之，實體 bean 從標准化和業界最佳實踐中受益，簡化了企業開發的某些復雜性並提供引人注目的基於組件的設計。
實體 bean 的缺點
雖然實體 bean 確實有一個令人印象深刻的特性列表，這為它們添色不少，但我們還是要考慮它們的缺點，其缺點如下：
設計復雜。容器管理的服務和自動透明持久性的代價很高。它們在幾個級別上給應用程序設計帶來復雜性。首先，為了避免網絡開銷並強制遵守業務規則，幾乎總是通過會話 bean 訪問實體 bean。因此，每個事務至少涉及兩個企業 bean（往往會多得多）。涉及的組件越多，則體系結構的設計、編碼和維護就變得越復雜。其次，存在自動操作成本。容器有點類似於有魔力的黑盒。只要它認為適當，就會調用 bean 回調方法，它可隨時選擇創建和破壞 bean 實例，激活和鈍化 bean，並且將其狀態存儲到持久數據存儲中或從其中裝入。應用程序代碼無法控制這些事情發生的方式或時間。從積極的方面看，容器的功能減少了編寫業務邏輯時要考慮的問題數量。從消極的方面看，容器對裝入條件和數據請求模式的響應是不可預知的，所以必須在開發過程中添加大量的基於方案的裝入測試。
較長的構建周期。由於企業 bean 和（尤其是）實體 bean 的復雜性，所以一次迭代（設計／構建／測試／集成／測試／部署）所花的時間比可比較的 Java 持久性解決方案所花的時間長兩到三倍。
響應時間。根據服務器上的負載和所請求實體 bean 的相對大小，實體 bean 的查詢可能有不達標的響應時間。實體 bean 在本質上受限於 bean 實例的粒度。要麼必須裝入整個 bean，要麼根本無法裝入 bean。該粒度會促使體系結構變得更復雜，因為唯一的選擇就是用較差的響應時間使 bean 保持原樣，還是將數據分成更小的實體，從而使系統體系結構變得更復雜。
資源使用情況。所有企業 bean 都是資源霸占者。實體 bean 大概是最大的霸占者。雖然這將視使用的應用程序設計模式以及供應商如何有效地設計其實體 bean 實現而變化，但實體 bean 仍傾向於消耗大量的服務器資源。
總之，實體 bean 的缺點是復雜性和較長的構建周期，從而使設計和開發包含它們的系統變得更困難。在生產中，實體 bean 因霸占資源和對大實體的並發請求響應極慢而聲名狼籍。
會話 bean 和 JDBC
無狀態會話 bean 的受歡迎程度不象實體 bean 那樣大起大落（請參閱 側欄）。事實上，在普及和功能方面，無狀態會話 bean 自 1999 年（當年發行了 EJB 規范）開始就一直保持穩定和可靠。它們產生性能極佳的結果和有效的資源合用，並且是 EJB 系列的一個重要工作程序組件。無狀態的會話 bean 的穩定性和可預知性使它們成為管理持久企業數據的優秀候選者。
無狀態會話 bean 常常與 JDBC 相結合來創建可靠的持久數據管理解決方案。在下面兩節中，我們將衡量該解決方案的優缺點，但我們將不探究這兩種技術本身的細節。如果您需要學習有關無狀態會話 bean 或 JDBC 的更多內容，請參閱 參考資料。
它是如何工作的
因為會話 bean 沒有一種固有的數據訪問機制，所以它們必須使用資源管理器連接工廠。 資源管理器是 J2EE 容器的一個組件，它管理特定類型資源的整個生命周期，包括連接合用、事務支持以及使實際連接變成可能的任何必需的網絡協議。 連接工廠是用於創建至資源管理器的連接的對象。EJB 規范定義了 JDBC、JMS、JavaMail 和 JCA 資源的資源管理器。
在基於會話 bean 和 JDBC 的持久性體系結構中，會話 bean 將所有訪問命令都委托給 JDBC 層。在接收調用時，會話 bean 使用 JDBC 來獲得實現 javax.sql.DataSource 接口的對象。然後，返回的對象充當 java.sql.Connection 對象（由 JDBC API 定義）的資源管理器工廠，這些 java.sql.Connection 對象實現與數據庫管理系統的連接。一旦獲得了 Connection 對象，其余的持久性代碼和業務邏輯（查詢、更新、存儲過程調用、結果集浏覽和事務提交／回滾等等）就是純 JDBC。
會話 bean／JDBC 的優點
會話 bean 和 JDBC 成為處理企業數據持久性的極佳組合。該組合最受認可的優點如下：
設計簡單。從體系結構設計觀點來看，通過會話 bean 來直接處理數據管理比使用實體 bean 簡單得多。
細粒度的控制。因為會話 bean 是通用的工作程序組件，所以它們允許開發人員完全控制整個持久性過程，包括高速緩存、持久性、並發性、同步及其它。相反，CMP 實體 bean 不允許開發人員控制持久性機制，而 BMP 實體 bean 僅使開發人員能夠定義應發生什麼，而不能定義應在何時或什麼樣的情況下發生。
成熟。JDBC 存在了七年左右！而實體 bean 出現至今只有三年多的時間。JDBC 的可靠性和最佳實踐對於 J2EE 持久性機制的開發來說是一筆非常寶貴的資產。
速度。因為開發人員完全控制在會話 bean 中使用的數據訪問機制，所以可以針對某些任務優化數據訪問和持久性邏輯。由於直接和有目的的操作，這可以產生極快的響應時間。
總之，會話 bean 和 JDBC 的組合能使開發人員對數據管理語義有細粒度的控制權，這一組合利用健壯且成熟的數據管理技術，支持功能優化，並將它全部封裝成一個相對簡單的組件體系結構中。
會話 bean／JDBC 的缺點
到目前為止都在談論會話 bean 和 JDBC 組合的優點，但它也有一些缺點。缺點如下：
實現復雜。雖然這種系統的體系結構設計相當簡單，但實際的會話 bean 實現常常十分復雜。如果應用程序的數據需求相當復雜，那麼可能就無法實現管理數據庫連接、確保數據完整性以及正確處理事務語義這些關鍵任務。開發人員常常需要實現某種類型的高速緩存同時確保最優性能。構造這種高速緩存機制使該系統的開發和維護進一步復雜化。
非固有的事務性。實體 bean 本質上是事務性組件，這些組件具有可配置的事務語義；而會話 bean 沒有。將事務語義直接編碼到應用程序代碼中時，開發人員必須處處小心以確保每個功能的業務規則、流控制和事務完整性都得以保護並且可以容錯。在實體 bean 開發中，這些細節都由容器處理。
持久性不是自動的或者得不到保證。在實體 bean 操作中，容器處理 bean 狀態的持久性，並確保這種數據得到保護，供以後使用。對於會話 bean，將數據保持在安全、長期的數據存儲中是開發人員的責任。
總之，與 JDBC 結合的會話 bean 遭受三個關鍵問題：bean 的實現常常是復雜的；會話 bean 沒有固有的事務性；持久性機制不是自動的或者得不到保證。
進行調用
盡管還有不足，J2EE 架構設計師已開始宣布帶有原始 JDBC 調用的純無狀態會話 bean 是最安全和最受推崇的數據持久性機制。這並非主要因為該組合是優於實體 bean 的解決方案（兩者各有所長），實際是因為它有推動力。在實體 bean 很快脫穎而出又很快失寵的時候，對會話 bean 和 JDBC 的接受程度卻隨著時間的推移緩慢而穩定地積累起來。
不管當前趨勢是什麼，仔細地權衡實體 bean 和會話 bean 與 JDBC 組合的優點總是值得的。下面的列表標識了比較這兩個數據持久性解決方案的四個關鍵方面：
讀／寫需要。需要經常讀取且從不更改或偶爾更改的數據最好由會話 bean 與 JDBC 組合來處理。開發工作會簡單直接，並產生極好的響應時間。
如果數據需要頻繁更新並支持許多並發請求（因此有許多並發更改），那麼實體 bean 是當然的選項。在面對數據的並發請求時，為確保數據完整性、同步和頻繁的持久性而構建一種機制所涉及的復雜性簡直太難克服了，而且不值得花時間和精力來創建它。
事務支持。CMP 實體 bean 使開發人員不必關心事務環境。所有事務細節都在 bean 的部署描述符中聲明。如果可以接受這一級別的控制，那麼 CMP 實體 bean 無疑提供了最容易的解決方案。如果需要更多的控制，那麼 BMP bean 允許開發人員定義應該采取的操作，而不必為應該何時觸發這類操作來編寫業務規則。對於最大級別的控制，應該使用會話 bean。會話 bean 會管理涉及 CMP 和 BMP 實體 bean 的復雜事務，以及少數直接訪問數據庫的 JDBC 調用。
上市時間。CMP 實體 bean 顯然是所有 J2EE 持久性機制中唯一一個上市時間最快的。聲明數據類型和名稱，定義部署設置，然後由應用程序服務器和供應商工具負責其余部分。很難講 BMP 實體 bean 和會話 bean 與 JDBC 組合哪個能排上第二快的解決方案。一方面，BMP 會更快，因為容器正代表 bean 提供如此多的生命周期服務。而另一方面，會話 bean 會領先，因為它們沒有 BMP 那麼復雜，所以構建／測試／部署周期更短。最後，在這三種解決方案針對您的特定項目時給它們排序只是整個比較過程的一部分。還必須針對下一個類別（資源使用情況）來權衡這個評級。
資源使用情況。實體 bean 因消耗大量的資源（尤其對特別大的實體進行並發請求時）而聲名狼籍。與之相比，會話 bean 和 JDBC 數據源連接是非常輕量級的，只需要少量的服務器資源。有關這一點的更多信息，請閱讀本系列的第一篇文章“J2EE technologies for the stateless network”（請參閱 參考資料中的 J2EE Pathfinder系列文章）中概述的無狀態會話 EJB 實例-合用模型描述。
結束語
在 J2EE 探險者系列的第三部分中，我們針對數據持久性將實體 bean 與會話 bean 和 JDBC 組合作了比較和對照。這裡討論的方案並未涵蓋所有情形，但是它們代表了實體 EJB 組件和會話 EJB 組件的一些最常見用法。
下個月，我們將通過比較實體 bean 和 Java 數據對象（Java Data Object）來繼續研究 J2EE 數據持久性機制。祝您到那時“探索”愉快！
