作者：
江南白衣 上次FB的吹水摘錄：
除JDBC外的數(shù)據(jù)訪問技術包括EJB，Hibernate，JDO，iBatis等，但凡是ORM的總要面對相同的困境，如果透明持久化的，苦惱就更多 --Java數(shù)據(jù)訪問技術依然在緩慢跨越鴻溝，.Net社區(qū)的同學用不著眼熱心跳：
1.查詢語言--紛紛重回原來極想擺脫的sql，但實現(xiàn)得又不如SQL成熟。 因為QueryObject，Criteria API的可讀性太差，最后所有技術方案都回到它們原來一力想擺脫的SQL的路上。而且，因為是重新倉促設計，都不如sql 的成熟，總有很多做不到的地方。像剛開始的EJB QL，幾乎什么都做不了，而hibernate 3.0 HQL把h2的代碼拋棄了重新實現(xiàn)才達到相對滿意的水平。
2.積極載入和懶惰載入--不能如sql般每次隨需定制
ORM與jdbc訪問的區(qū)別，就是以包含關聯(lián)對象的對象，而不是以sql自由定制的ResultSet，作為數(shù)據(jù)載入的主體。
積極載入策略在載入訂單對象時，會接著載入顧客對象、產(chǎn)品對象，而如果產(chǎn)品對象又包含類別對象時.....整個數(shù)據(jù)庫被拖了一小半出來。即使不玩連連看，clob對象的胡亂載入就夠頭痛了。
與此對應的就是懶惰載入策略，比如EJB的初始版本，據(jù)聞每個屬性查詢一次數(shù)據(jù)庫，數(shù)據(jù)庫往返次數(shù)多得嚇人。
ORM方案會讓用戶自行定義這兩種策略來達到平衡。一般默認采用積極載入，在一對多關聯(lián)上定義lazy load，還有統(tǒng)一定義積極載入的層數(shù)。到了hibernate 3，更可以在列級別上定義lazy load。
問題是，上述的定義都在hbm文件，
每種對象的載入策略只能定義一次。而不能像jdbc那樣，
根據(jù)不同的情況select不同的結(jié)果列。
順帶一個問題是那些信息不完全對象，比如產(chǎn)品只有序號和名字，不帶其他信息時，在一個純面向?qū)ο蟓h(huán)境里不好表示，hibernate提供的component方案也不是太好。
3.透明持久化--對POJO的一些臨時操作也會被持久化 因為持久化是透明的，很容易就會誤用，對POJO進行的一些臨時操作，一不小心就被保存進數(shù)據(jù)庫中。再加上Session，事務的混亂，遠遠沒有用jdbc跑DML語句那么容易搞清楚發(fā)生的事情。
而且，不是每個程序員都能習慣新的透明持久化環(huán)境，都對所用ORM系統(tǒng)的持久化策略理解深刻。何況這些策略以及整合它們的框架如Spring，還經(jīng)常毫無提示的在升級時發(fā)生改動!!!
所以，每個使用ORM的團隊，在項目過程里總會有鬧鬼的幾天......