J2EE持久化策略考察——為項目做技術選型準備的一點資料

背景

  O/R映射技術的出場順序：

1997年-1998年：TopLink，CocoBase，ODMG

1999年-2001年：Entity Bean，JDO

2002年-2003年：TopLink，Hibernate，iBatis數據庫層

2004年：JDO穩步發展；Hibernate飛黃騰達

功能

以下出自Rod Johnson《J2EE設計開發編程指南》

使用EJB2.0實體進行O/R建模的限制：

盡管引進了各種重要增強，但根據制定，CMP實體組件依然是O/R映射的一個基本形式。EJB規范忽略了O/R映射方面最難辦的部分問題，并且使利用關系數據庫的部分能力變得沒有可能。例如：

1.        不支持開放式加鎖

2.        對批量更新的支持極差（EJB2.0主方法至少使它們有可能，但容器——和EJB QL——在實現它們方面沒有提供任何幫助）

3.        從一個對象到單個表的映射概念是有限的，而且EJB2.0規范沒有建議EJB容器應該如何解決這個問題。

4.        不支持被映射對象中的繼承性。像WebSphere那樣的有些EJB容器把這實現為一個專有的擴展。

在現實經驗方面，實體組件遠遠落后于那些最好的O/R映射框架。不過，O/R 映射框架一直是很昂貴的產品（盡管這種狀況在2002年似乎正在發生改變。）據筆者所知，目前還沒有任何開源產品提供一個企業強度的O/R映射解決方案（注：不過現在有Hibernate了）。

以下出自Rod Johnson《J2EE without EJB》

如果出現下列征兆，就可以考慮使用O/R映射：

1.        針對領域對象的“加載/編輯/存儲”流程，例如先加載一條產品記錄，對其進行修改。

2.        對象以批量查詢的方式取出，但更新和刪除則是單獨進行的

3.        大量對象需要積極的緩存（通常出現在“讀操作遠多于寫操作”的情況下，如Web應用）

4.        在領域對象與數據庫表/字段之間有一個相當自然的對應關系。

5.        不需要對SQL進行特別的優化。在大多數時候，好的O/R映射解決方案可以把生成的SQL優化得相當好，例如Hibernate的“方言”（dialect）支持；但一些特殊的SQL優化只有在完全關系型的方式下才可能進行。

O/R映射兩大好處：

1.        可以不必編寫重復的JDBC代碼處理領域對象的實例（意味著編寫的代碼少，縮短開發周期；進一步意味著維護的代碼少，意味著容易維護）

2.        透明持久化：完善的O/R映射工具可以在事務提交時自動將修改后的數據持久化到數據庫。正如前面所說，只有真正被修改的數據才會被提交，應用代碼無需進行任何臟數據檢查。

Entity Bean的敗筆（指的是EJB2.0）

1.        EJB QL（CMP查詢語言——注：與之對比的是Hibernate的HQL）的能力非常有限，迫使開發者不得不編寫SQL語句或者依賴于應用服務器廠商專有的擴展功能。

2.        Entity Bean的性能經常很糟糕，因為組件管理和方法攔截造成了巨大的開銷，尤其是在處理大結果集時更加明顯。只有對于大量緩存的對象，它的性能還算差強人意。

以下出自《Pro Hibernate》

為什么不用EJB來存儲，顯示，查詢數據庫中的數據呢？嚴格的說，EJB服務器支持兩種類型的持久化，就是BEAN管理的持久化（BMP）和容器管理的持久化（CMP）。在BMP中，Bean自己負責執行所有的SQL語句來完成存儲和查詢數據。換句話說，我們自己要去編寫JDBC邏輯代碼。另一方面，CMP是由容器來執行存儲和檢索bean數據的工作。

我們這里不選擇EJB的原因如下：
1 CMP實體bean需要和數據表一對一的映射
2 它們很慢
3 有時候要人工參與的去決定哪一個bean字段對應表的哪一列
4 它們對方法命名有要求
5 EJB的容器是重量級的
6 它們和容器依賴強，不容易移植

下面看看Hibernate的特點：
1 不需要強制映射一個POJO到一個表，不強制一對一的關系
2 盡快啟動并加載它的配置文件時會對性能有些負載，但總的來說，它是很快的工具
3 和容器沒有強依賴，很方便的移植
4 可以很輕松的處理serializable POJOs

以下出自網上評論

entity   bean是我見過的O/R   mapping中最差的一個。它對實體的描述能力太弱（實際上不支持繼承），對實體對象的限制太多（要求繼承接口），查詢能力太弱（不支持動態查詢，更不支持非對象查詢）。現在就連Sun的人都已經不推薦用entity   bean了，他們用JDO。在O/R   mapping這里，Hibernate和Castor都比entity   bean要好。

性能

以下出自Rod Johnson《J2EE設計開發編程指南》

實體組件性能主要取決于EJB容器的實體組件高速緩存策略，而高速緩存又取決于該容器所運用的加鎖策略。

使用實體組件可能會產生比主流的持久性替代方法更糟糕的性能，除非你的應用服務器有一個有效的分布式和事務性實體組件高速緩存器，否則開發人員需要把大量的精力投入到多部署上。在后一種情況中，性能將由應用的性質來決定：①對數據主要進行只讀訪問的應用將會運轉得很好，而②對數據主要進行寫訪問的應用從高速緩存中將得不到什么好處。

這為什么重要呢？因為沒有高效的高速緩存，實體組件性能可能會非常差。

來自實體組件模型的高效性能取決于下列條件：

1.        數據在被訪問時可能被修改。除了只讀實體的專有支持外，實體組件采用一個讀—修改—寫模型。

2.        修改發生在個別的被映射對象級別上，而不是作為一個集合操作（也就是說，更新可以利用Java中的個別對象來有效地完成，而不是對一個RDBMS中的多個元組進行更新）

實體組件在許多情況下為什么有性能問題呢？

1.        實體組件使用一種“以一概全”的方法。正如我們使用RDBMS時所見過的，實體組件抽象可能會使有效地訪問持久性數據變得不可能。

2.        實體組件約定是嚴格的，進而使編寫有效的BMP代碼變得不可能。

3.        調整實體組件數據存取是很困難的，無論我們使用BMP還是CMP。

4.        實體組件具有相當大的運行時開銷，即便使用本地而不是遠程接口。（一個實體組件將始終比普通Java類有一個大得多的開銷）

5.        在實踐中，實體組件性能常常會下降到O/R映射性能，而且不保證一個J2EE應用服務器供應商在這個領域內擁有很強的專門技能。

實體組件運行效率特別差，而且由于大型結果集的緣故而耗用過多的資源，尤其在結果集（比如搜索結果）沒有被用戶修改的時候。實體組件對總是在個別記錄級別上被修改的數據有最佳的運行效率。

BMP中蘊含的性能問題：n+1查詢發現者問題

問題本質：BMP實體的約定要求開發人員實現發現者來返回實體組件的主鍵，而不是返回實體。

例子：使用SQL（這就是所謂的n+1查詢發現者問題中那個1）查詢5000個User，返回后，EJB容器會創建或重用5000個User實體，然后根據每個主鍵用來自5000個獨立查詢（當然查詢是使用select語句了，這就是所謂的n+1查詢發現者問題中那個n）的數據填充這些User實體。這就意味著總共有n+1條select語句了。

復雜性

       EJB2.0需要3個Java文件兩個描述文件才能搞定，而Hibernate則只需要1個Java文件和一個描述文件，如果數據庫中有1000張表要映射成EJB實體和Hibernate的POJO，那么就是5000個文件和2000個文件的差別，那如果需要1萬個EJB實體，就意味著是5萬和2萬的差別了。

結論

    總而言之，EJB實體bean（就是J2EE的O/R Mapping方案）實現的功能只是Hibernate實現功能的一個子集，而且采用了笨拙和低效的方法實現的，而且復雜性遠高于Hibernate（開發，部署，維護），此外其可測試性方面和Hibernate也沒法相比。

參考資料

1.         [原創]Pro Hibernate 3筆記和小結（2）之第一章Hibernate入門

2.         Rod Johnson的兩本巨著