ORM透明持久化方案面對的共同困境

原文出處及評論:http://www.blogjava.net/calvin/archive/2006/01/05/26791.html

  作者：江南白衣    
 
   上次FB的吹水摘錄：

     除JDBC外的資料訪問技術包括EJB，Hibernate，JDO，iBatis等，但凡是ORM的總要面對相同的困境，如果透明持久化的，苦惱就更多 --Java資料訪問技術依然在緩慢跨越鴻溝，.Net社區的同學用不著眼熱心跳：

     1.查詢語言--紛紛重回原來極想擺脫的sql，但實現得又不如SQL成熟。
        因為QueryObject，Criteria API的可讀性太差，最後所有技術方案都回到它們原來一力想擺脫的SQL的路上。而且，因為是重新倉促設計，都不如sql 的成熟，總有很多做不到的地方。像剛開始的EJB QL，幾乎什麼都做不了，而hibernate 3.0 HQL把h2的代碼拋棄了重新實現才達到相對滿意的水平。

    2.積極載入和懶惰載入--不能如sql般每次隨需定製
       ORM與jdbc訪問的區別，就是以包含關聯對象的對象，而不是以sql自由定製的ResultSet，作為資料載入的主體。

       積極載入策略在載入訂單對象時，會接著載入顧客對象、產品對象，而如果產品對象又包含類別對象時.....整個資料庫被拖了一小半出來。即使不玩連連看，clob對象的胡亂載入就夠頭痛了。

      與此對應的就是懶惰載入策略，比如EJB的初始版本，據聞每個屬性查詢一次資料庫，資料庫往返次數多得嚇人。

      ORM方案會讓使用者自行定義這兩種策略來達到平衡。一般預設採用積極載入，在一對多關聯上定義lazy load，還有統一定義積極載入的層數。到了hibernate 3，更可以在列層級上定義lazy load。

      問題是，上述的定義都在hbm檔案，每種對象的載入策略只能定義一次。而不能像jdbc那樣，根據不同的情況select不同的結果列。

      順帶一個問題是那些資訊不完全對象，比如產品只有序號和名字，不帶其他資訊時，在一個純物件導向環境裡不好表示，hibernate提供的component方案也不是太好。

3.透明持久化--對POJO的一些臨時操作也會被持久化
     因為持久化是透明的，很容易就會誤用，對POJO進行的一些臨時操作，一不小心就被儲存進資料庫中。再加上Session，事務的混亂，遠遠沒有用jdbc跑DML語句那麼容易搞清楚發生的事情。

    而且，不是每個程式員都能習慣新的透明持久化環境，都對所用ORM系統的持久化策略理解深刻。何況這些策略以及整合它們的架構如Spring，還經常毫無提示的在升級時發生改動!!!

    所以，每個使用ORM的團隊，在項目過程裡總會有鬧鬼的幾天......