零雨其蒙's Blog

如果一個團隊，沒有一個很懂Hibernate的人，卻貿然使用Hibernate，這本身就是風險管理的失敗；
并且團隊中的成員又不是很強（因為高手組成的團隊，即使之前不懂Hibernate，但是他精通SQL，精通數據庫建模，精通JDBC，精通J2EE，現學也還是會很厲害），還搞個新技術去做，那么風險管理做的就太糟糕了。

我覺得咱倆的討論就像gigix在JE上跟一個人的討論一樣，我Blog里摘錄。

@shinewang
說到底，大家還是JDBC的思維太積深了。
解決這個問題也很簡單，我們用泛型DAO，然后將CRUD的語義跟JDBC一致，如果搞不清楚Hibernate細節，那就不用延遲加載，不做關聯映射，每個實體一個DAO~~~

因此我覺得大家伙都是專業人士，就不要看那些給學生看的垃圾圖書了，放著好好的Reference為什么不讀呢？

還有一點，就是學習技術最好不要看中國人寫的圖書，質量極差，誤導性極強~~最好的方法是看Reference入門，然后可以看In Action系列~~

@shinewang
可能你理解的快速入門指南是Get Started（Reference的第一章，里面的確沒有談及Update），而我認為Hibernate Reference就是所說的快速入門指南了。而詳細說明書則是Hibernate實戰那本書。閱讀一遍Reference大約只需要3天時間，因為一共才20章。
如果數據庫，J2EE基礎很差，而且一個項目的周期只有2個月，那就不要用Hibernate了，我發現很多人看了那個Reference時說看不懂，很多都是因為他連JDBC、事務隔離級別，數據庫范式，和典型的開發模式都不知道，看不懂就是自然的了。
如果項目周期有兩年，那么花1個星期把Reference里的內容都實驗一遍，應該基本不會出問題的。
如果您有時間的話，可以寫Hibernate的十大陷阱，我覺得更有益處~~~

@shinewang
1 對于延遲加載，OSIV使得你不必要關心事務，也沒了托管的概念，是一種簡化
2 ActiveRecord是怎么做的？無非就是約定優于配置+參數綁定。我真不知道還有什么第三種方式能能系統自動的就知道程序中的username和user_name是對應的，用怎么知道username和f_user_name是對應的，大家習慣都是不一樣的。按照Fowler的說法，ActiveRecord是在Transaction Script和ORM中的一個折衷。
3 Hibernate的哲學是管理對象和數據狀態，而不是做數據操作。你把他理解為數據操作就錯了，實際上，Hibernate的操作是狀態轉換，底層才是JDBC的操作。因此這不是過度設計，只是一種理論的實現罷了。
4 最后這點確實是問題的關鍵，因為我們關注的方面不同。
如果是小應用，非要選擇Java的話，持久層還是用iBatis或者用Spring的JdbcTemplate比較容易理解。但是，如果你懂Hibernate的話，小應用使用Hibernate同樣非常敏捷，我們項目中的基礎數據維護就是用Hibernate做基礎，然后編寫了一個通用的DAO（繼承自泛型DAO），只要把實體的類set進去，然后就可以對這個實體進行CRUD操作了。另外Hibernate的屬性與字段默認對照你是可以重寫方法變成你喜歡的樣子，比如讓username自動去對應user_name（開源就是好~~）。
總而言之，并不是Hibernate有十大罪狀，而是：
1 沒有理解Hibernate是什么
2 不看說明書就使用家用電器。在這里我不說家用電器的事，那時我買了件馬克華菲的衣服，洗了一次發現有點掉色，心里暗想這么貴的衣服怎么質量這么差。拿去洗衣房，洗衣房的阿姨告訴我，這種大品牌的衣服，在衣服的內兜或者底襟的地方都有洗滌說明的，我一看，才發現自己洗錯了。這件事情告訴我，每件事情都有其內在客觀規律，你必須要遵守的。

@shinewang
1 我并沒有說你不會，我知道你會配置OSIV，但是你好像并不知道OSIV的來歷，要不然你也不會說出是延遲加載導致了OSIV。
你也會配置Hibernate映射，但是我不知道將你的程序和數據庫模式對應上除了寫映射和SQL語句（或者類似物）還有什么第三種方式？既然沒有，那么寫映射肯定更簡單，而且Hibernate提供很好的默認值，怎么會說繁瑣呢。
你或許只會操作，但是并不懂得背后的原理，有些甚至都不會操作。
2 我不認為Hibernate有什么過度設計的問題，只能說明那些問題你可能沒有意識到，過去我也是這樣，不知道你讀沒讀過Martin Fowler的企業應用架構模式和Gavin King的Hibernte實戰以及Rod Johnson的三本書，我覺得那些在開發中我們會遇到的問題或者麻煩，Hibernate都周到的用世界級的方法幫我們解決了。
3 Hibernate3已經和Hibernate2是不同的包了，很多東西都改了，新版本只能說是日臻完善，越來越好，我是沒看出來他有什么地方是妥協的。另外不知道你用沒用過EJB2.1，那個東西很簡單，關鍵是很多問題沒解決啊
4 新的Hibernate那就應該是EJB3了，這個項目也是Gavin King主持的，除了標準化了基礎設施，也沒什么太多新的東西，畢竟ORM的理論Fowler8年前就論述清楚了，而且像Toplink這樣的商業級ORM都有十年歷史了

@lin
10年前就有OR不匹配問題了

作者的觀點十分荒謬可笑，估計高手都懶得回復你了：
1. 復雜的實體狀態
持久，瞬時，托管。三個狀態非常完美的表示了對象和數據庫的交互（綁定了Session，就將內存和數據庫連接起來了），綁定了Session，如果一個對象在數據庫中沒有對應的記錄，而只存在于內存中，就是瞬時的；如果一個對象在數據庫中有對應的記錄，而且現在在內存里，就是持久的。沒有綁定Session，如果一個對象在數據庫里有對應的記錄，而現在它在內存中，就是托管的。
請問這復雜嗎？
關于自動同步問題，只要你讀過一遍那個薄薄的Hibernate開發手冊，就該知道這些問題啊，不看使用說明書，就使用產品，這是很多人的通病吧。
2. Lazy Load 與 Eager Load
Open Session In View本質是一次會話一個事務這種模式，你當然可以使用托管對象模式，誰說的Lazy Load直接導致了OSIV？
3. Open Session In View
同上
4. 級聯
級聯刪除是數據庫本身就有的選項，至于級聯插入和修改，以及集合元素的remove都是符合語義的，我知道你的擔心，怕關聯對象自動插入出現問題，計算機不是擲骰子，因此這種擔心是多余的。
5. 批量更新與緩存不一致
你可以修改緩存策略，不想用就不用。更何況大型的網站怎么可能不用緩存呢，即使你不在應用層加，很多大型數據庫也是會帶緩存的。
6. 配置繁瑣
數據庫和程序是怎么對應起來的，你總得在一個地方標明吧，要不系統怎么知道你是怎么對應起來的。你用JDBC就是寫insert 字段 vlaues（值），將字段和值對應起來，只不過Hibernate配置換了個地方，把這種對照關系寫在了配置文件里。而且寫一次就OK了，你不必寫update的時候，再去看看程序中的哪個變量與數據庫的哪個字段要對應上。
Hibernate提供了默認的配置，是在簡化你的開發啊。
7. HQL
HQL在做些簡單的查詢時使用可以簡化你的代碼，而復雜的查詢就不要用了，稍微復雜點可以用QBC，實在不行了用SQL，不同的復雜程度，用不同的解決方案，Hibernate想的很周到。好比你吃粉條最好用筷子，喝湯最好用勺，啃排骨最好用手。
8. 太多的查詢方案
見上一個問題
9. N+1次查詢
N+1次查詢和笛卡爾乘積是一個魚和熊掌不可兼得的權衡，Hibernate提供了不同場景的不同方案。和第7個問題一個道理，你應該使用恰當的方法。
10. 性能問題
Hibernate只是幫助你生成了一些SQL語句，創建和管理了一些對象，這兩個過程你不用Hibernate也會自己做，你可以把自己寫的代碼，跟Hibernate執行過程做個對比，通常情況下，你寫的SQL，未必有Hibernate生成的好，畢竟人家是專業的SQL專家寫的SQL語句。

最后一個故事是莊子里的吧
每個故事都很好~
很受啟發

PO應該和Hibernate應該沒什么必然聯系吧，我第一次見到這個詞好像是在Core J2EE Patterns里，TO也是在這本書里見的，Rod Johnson批判了TO這樣的啞對象破壞了OO，而我覺得從領域層到表現層的傳遞有了VO，從領域層到持久層的傳遞有了PO，為什么還非要TO呢？

"從概念上DTO和PO仍然屬于不同層,后者才是操作數據庫的."我覺得此話欠妥，PO應該是和表對應的，跟表是一種對應關系，而操作數據庫的應該是DAO。最近在研究《UML和模式應用》，希望討論之。