shinewang

關鍵是Java做不出ActiveRecord吧...  回復  更多評論
  

支持  回復  更多評論
  

我2004年就不用Hibernate了.  回復  更多評論
  

沒有垃圾的技術，只有愚笨的使用者。
你想想，Jboss公司的EJB都吸取了很多hibernate的方案，jboss的總裁比你傻嗎？
自己沒有用明白就不要這里瞎叫喚，看看文檔，多做幾個項目，比什么都強。  回復  更多評論
  

如果是原創，我贊賞樓主的批判，鄙視XX的回復。
任何事物都有兩面性，指出一個事物的反面不見得就不用它，而只是表明它還有改善空間。只看到光環而看不到陰影的盲目崇拜者是最可悲的。  回復  更多評論
  

@xx
項目做得越多就越感到hibernate的種種弊端，對上面提到的問題我當然知道解決的方法或者適用的環境，如果有時間會針對這些問題的解決方法寫一篇文章的。我只是想指出普遍彌漫在Java開發界里追求大而全而忽視易用性的的設計思想，這種錯誤的思想帶來復雜性的同時，往往給項目埋下了隱患，因為我們無法保證團隊里的每個成員都對清楚地了解這類陷阱，即使了解也無法保證在編碼過程中不發生的疏忽，想要避免這些問題的發生最簡單最有效的就是要有一個表義清晰、簡單務實的底層設計，這就是大家都知道的KISS(Keep It Simple Stupid)原則。  回復  更多評論
  

本人弄的一個快速開發平臺ajf（agile java framework）
里面有輕量級的ORM組件，大家可看看，消遣娛樂下
http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html" target="_new" rel="nofollow">http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html
http://hi.baidu.com/ajf8  回復  更多評論
  

寫這篇文章的時候就知道總會引起一些爭議，所以寫完后當作草稿放了幾個月了，促使我今天把它發出來的原因就是最近公司的項目中又有一個因為忽視hibernate自動同步而造成的Bug。發這篇文章也是提醒正在使用Hibernate的開發者是否存在這方面的疏忽。  回復  更多評論
  

稍微有點規模的項目不用Hibenate問題會更多。  回復  更多評論
  

hibernate從總體上說設計思想還是很不錯的，但高級的東西總是需要大量時間和精力去學習和研究。這也是hibernate的弊端。 這就象有一把絕世好劍，用好了，可以天下無敵，用不好可能會反傷了自己。

軟件的發展歷史也說明了這一點，想起當前使用面向過程的方式進行程序設計，雖然沒有現在面向對象的思想選進，但程序結構很簡單，實現也很容易，也沒這么多設計模式，說起來很省力。而現在的OOP，雖然看似很先進，但實際上大大增加了程序的復雜度，之所有現在OOP的設計思想使程序設計更簡單，是因為程序規模的增長已經遠遠超過了面向過程升級到OOP所增加的復雜度。  回復  更多評論
  

LZ 說的有道理，我個人認為 hibernate 適合國外項目的開發，開發國內的項目用起來比較痛苦。  回復  更多評論
  

看怎么用了，很多公司做項目都在用。Hibernate其實可以說是一種思想，如果lz是工作3年以上，就不會說這樣的話了  回復  更多評論
  

@徐堯
在用不代表沒有缺點，看不到現有技術的缺點就不會有新技術的產生。對象關系映射的模式不止Data Mapper一種，Data Mapper的實現也不止Hibernate一種，只是在Java領域Hibernate使用的比較廣泛罷了。  回復  更多評論
  

個人認為這種基于ORM的技術最好與語言和開發工具融合，也就是屬于語言或開發工具的一部分，無縫結合，這要比framework更容易使用，說實話，所謂framework，實際上就是一個大大的patch，正因為語言不支持，才會做成framework來彌補這個不足，就象AOP，如果語言支持，那誰還會再實現一套AOP framework？  回復  更多評論
  

@銀河使者
趨勢是這樣，云計算的環境下就不需要ORM了，而是完全的面向對象的數據訪問  回復  更多評論
  

@銀河使者
讓人想起了Linq2SQL，雖說那東西還有很多問題，但是確實往你說的方向上前進了。  回復  更多評論
  

技術是拿來用的，不是來比較的。。自己認為不好用，那就用別的。。  回復  更多評論
  

出來任何一個東西都有人說不好
請問你到底懂多少？
說到底，笨的永遠都是自己  回復  更多評論
  

@比
你怎么肯定是我不懂，你怎么肯定團隊中的每個成員都懂Hibernate，看不到技術的缺陷而盲目使用必然會給系統帶來風險，只有充分認識到技術的優點、缺點，才能做到在合適的地方正確地應用合適的技術。此外，在產品開發時沒有任何借口逃避對易用性地考慮，可以參考我在前面的回復。  回復  更多評論
  

@王生生
并沒有把Hibernate和其他框架比較啊。我很贊同技術是拿來用的，況且目前還沒有哪個java orm框架在成熟度上能和Hibernate相比（排除半自動的ibatis），但我信奉的另一句話是“你可以不做，但你不能不想”。  回復  更多評論
  

@xx
說得不錯，我支持。要有發展，就要把自己的眼睛放遠些，找一種技術的毛病要比學好一種技術簡單得多。
缺點和罪狀是兩個概念。如果沒有學好hiberante又沒學好語文，就別寫什么博客。
至少我們公司的項目都用hiberante，而且項目規模都是400萬以上的項目。有些項目將近2000萬。
有些缺點就不用，比如級聯操作，還有繁瑣的關聯關系，能簡化就簡化。一個功能豐富的手機不可能你每個功能都用，你要干什么，你在用什么，不是這個東西有什么，你才用什么。
我認識很多程序員，抱怨hiberante沒有ibatis好，不方便。放棄很容易，但你永遠都是一個程序員。  回復  更多評論
  

感覺lz和xx、開源之星等考慮問題的出發點不一樣，lz是從主動選擇技術的角度考慮hibernate的缺點和由此帶來的風險，xx、開源之星等是從被動接受、使用技術的角度考慮的，所以談不到一塊去。正如開源之星所說的“有些缺點就不用”，那不正是建立在先認識缺點的基礎上嗎？另外，我倒是覺得lz用缺點和最狀也是合適的，hibernate的這些缺點或者說是陷阱確實會“誘使”新手犯錯，hibernate犯了“教唆罪”，文字上夸張一下也沒錯，呵呵。  回復  更多評論
  

@ygafu
你不用hibernate，那你用什么？JDBC？
  回復  更多評論
  

@keer
支持。真的應該直接用JDBC么？

我剛開始工作的時候，有一個前輩告訴我：
不要隨便批評一個解決方案，除非你找到了更好的解決方案。
除非只不過想罵罵街。
  回復  更多評論
  

我是一個菜菜鳥，我雖然已經從事軟件開發快一年了，但是沒有真正的用過Hibernet，最近自己想做一個酒店管理系統，由于對Hibernet 沒有十足的信息，所以我還是決定直接用ＪＤＢＣ去連接數據庫，這樣我感覺踏實一點，等把hibernet了解的差不多的時候再去改造我的系統。  回復  更多評論
  

你說的也叫罪狀，大哥，現在都什么年代了，這點問題還解決不了，你提的問題10年前就出現過了  回復  更多評論
  

@ss
有說不能解決嗎，看看我在前面的回復  回復  更多評論
  

從一個框架的出現是為了更加方便于開發這個角度來說，hibernate是需要謹慎的使用的。
碰到復雜一些的問題確實需要研究一些資料，不能簡單的就解決---或者說沒有現成的資料可參考。
  回復  更多評論
  

@ss
10年前就有hibernate了？  回復  更多評論
  

我玩hibernate已經多年了,很贊同樓主的看法,hibernate實在不適合中國國情,無論你是新手還是老手,hibernate都會大大影響你的開發,調試,發布的難度,它最成功的地方不過是完美的實現了hql,但是,實在很不敏捷,越復雜的系統越不能用hibernate,因為它會在技術細節上浪費你大量的時間,就像ejb的性能問題一樣煩瑣,搞不懂為什么hibernate這幾年可以這么火,估計跟媒體宣傳有關.夸張地說一句,程序員的時間很寶貴,項目的壓力很大,學什么都不要花時間學hiberate.  回復  更多評論
  

關注口水帖。
shinewang，同意你的觀點，說實話，除非強制，我更愿意用jdbc來寫，如果說要支持多個db，我也愿意為此重寫sql。  回復  更多評論
  

hibernate的唯一作用，就是把簡單的事情搞復雜。你們都在討論hibernate的缺點，請問，它有優點嗎？
  回復  更多評論
  

JAVA這么好的技術，存在這些垃圾框架，真是讓人悲哀，Hibernate的的確確是垃圾，真是不明白還有這么多人瞎跟風，認為hibernate是好東西的，真是一點兒都不懂JAVA，如果不盡早排除這些JAVA邊緣垃圾，以后會影響JAVA的發展，從搞開發到現在沒有見過一個hibernate高手，也就是說只要我見過用hibernate做的系統，都是垃圾，這是事實！！！  回復  更多評論
  

作者的觀點十分荒謬可笑，估計高手都懶得回復你了：
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語句。  回復  更多評論
  

@lin
10年前就有OR不匹配問題了  回復  更多評論
  

@零雨其蒙
很多人沒有仔細看明白我的意思就忍不住開始噴了，早不想回復這個帖子，看到你寫了這么多，還是回復一下比較尊重，我寫這篇文章主要基于以下的出發點：
1、我只列了問題沒有寫解決的方法并不代表我不會，遇到問題想辦法解決，根據環境選擇合適的方案，我想是作為一個合格的開發者的必要條件
2、Hibernate有過度設計的地方，這些理念可能在理論上很完美，但是實踐中我已經看到多次開發人員因為沒有意識到這種過渡設計隱含的風險而造成Bug
3、Hibernate存在冗余的設計，畢竟Hibernate有段歷史了，歷史的包袱也不是能隨便拋掉的
4、如果Hibernate的開發人員重新設計一個新的ORM，我想肯定比現在的好吧  回復  更多評論
  

其實說來說去就是一個易用性的問題，有些看上去很易用的設計實際可能存在隱含的風險，如何界定什么是好的易用性，什么是不好的易用性，這個問題值得大家思考一下  回復  更多評論
  

@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都有十年歷史了  回復  更多評論
  

@零雨其蒙
1、OSIV是解決Lazy Load最簡便的方法，所以我說Lazy Load導致我們選擇使用OSIV，而OSIV又有副作用。
2、繁瑣是相對而言的，相比Rails的ActiveRecord而言確實要麻煩些。
3、我說的Hibernate的過度設計就是自動與數據庫同步，這看起來是一種智能的方式，其實是一種不良的易用性。
4、我和你意見的分歧主要在于我關注的是80%簡單的應用，特別是Web應用，你關注的是20%復雜的應用，也就是真正意義上的企業級應用，正像你說的Hibernate提供的是世界級的方法，能解決開發中我們會遇到的問題或者麻煩，確實如此，我在之前就說過了Hibernate立足于作一個完整的自動化的能夠適應各種環境的ORM，因此帶來了復雜性。不同的領域自然會形成不同的工具需要。  回復  更多評論
  

@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 不看說明書就使用家用電器。在這里我不說家用電器的事，那時我買了件馬克華菲的衣服，洗了一次發現有點掉色，心里暗想這么貴的衣服怎么質量這么差。拿去洗衣房，洗衣房的阿姨告訴我，這種大品牌的衣服，在衣服的內兜或者底襟的地方都有洗滌說明的，我一看，才發現自己洗錯了。這件事情告訴我，每件事情都有其內在客觀規律，你必須要遵守的。  回復  更多評論
  

@零雨其蒙
你舉的這個例子很合適，問題就在于現實生活中究竟有多少人會去仔細看說明書，現在很多家電廠商提供兩本說明書，一本是薄一點的快速入門指南，一本是產品的詳細說明書，大多數人都是看了快速入門指南就開始使用了，你的產品應該保證用戶在按照快速入門指南中描述的方法、模式、思維使用產品的基本功能不出現錯誤，更好的產品甚至不需要這本快速入門指南，用戶可以按照從其他類似產品獲得的使用經驗來使用。Hibernate就像你那件大品牌的衣服，很多開發者看了一些入門的指南、圖書就開始使用，然后某天出Bug了，最終“在衣服的內兜或者底襟的地方”發現是有“洗滌說明”的。你也許會覺得這是他們沒有仔細看詳細說明書造成的，但現實是開發者不可能放著項目不做而先花大量時間去琢磨透每個細節后才開始使用Hibernate，要真正學好Hibernate花費的時間可不是一個小數目，就算我們敢于花這筆學習時間上的投資，把手頭上的項目停掉，把時間都花在學hibernate上，又能不能保證每個開發者會去仔細琢磨，我覺得最終的結果是大部分開發者自認為學會了學好了其實則不然。Hibernate的自動化很多容易給人造成一種印象，以為這是個簡單的東西，其實但凡自動化的裝置本身就是一個復雜的東西，如果本身設計得不到位，容易產生比較較陡的學習曲線，容易產生錯誤，算上學習成本和修補錯誤的時間后使用效率不見得就比手動設備高。  回復  更多評論
  

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

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

@零雨其蒙
我說的快速入門指南就是指國內或者國外寫的比較淺的圖書，很多人往往是通過這類圖書學習Hibernate等開發技術的，看完后覺得已經掌握了，而Reference和講的詳細比較厚的圖書則成為了遇到問題才會去翻翻的參考書。罪狀無非是一個夸張的說法，對于其中的部分問題來說陷阱是一個更準確的詞匯。有時即使我們明明知道Hibernate的相關機制，還是不由自主地掉進Hibernate的陷阱中（當然概率很小，最多每年1、2次的樣子），我覺得本質上是因為Hibernate確實和人的一般思維有不匹配的地方。  回復  更多評論
  

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

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

@零雨其蒙
你自己都說了“那些給學生看的垃圾圖書”，學生既然是看這些書熟悉Hibernate的，畢業出來進了公司后就難免在這方面出錯，你可以要求他們去看reference，但你不能保證他真的看了，并且看懂了。實際上我講的是一個管理的問題，而你卻是單純的從技術上看問題，從技術上看，Hibernate對熟悉它的高手而言當然沒什么問題，但從管理上看，團隊并不是只是Hibernate高手組成的，這種情況下hibernate的復雜性就加大了出錯的概率，即便我們可以通過培訓、Code Review、單元測試來減小這種概率。  回復  更多評論
  

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

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


  回復  更多評論
  

理解 shinewang 的意思，
實際上，中國99%項目開發中都有新手，零雨其蒙 說老手使用 Hibernate 的時候不會出問題，這個我相信，然而，不可能所有的代碼都是老手在編寫，一旦有一個新手出現“忽視hibernate自動同步”的問題，那頭都大了，而且這種問題除非有完善的自動化測試工具，否則很難發現。
也許 零雨其蒙 的同事都很厲害，反正我碰到的項目組里面總有一些初級程序員。  回復  更多評論
  

@開源之星

你那400W的項目拿個出來給大家參考一下!或者一些常用的編程方式發布給我們看看!

要不然說個名稱也行!  回復  更多評論
  

有見地。  回復  更多評論
  

400w包方便面  回復  更多評論
  

@shinewang
非常同意樓主的觀點。
程序員都會有意識的維護自己掌握的知識體系，如果有人說自己掌握的技術有問題，那就等于說自己過去的學習是沒有價值的，這是程序員盲目性的一個體現。
既然大家都在討論Hibernate,Ejb等，那就說明大家都在做企業應用開發，但是有沒有人進行過深入思考，什么叫企業應用，這個行業有什么特點。根據我的了解，沒有哪個做企業應用的公司會把技術架構放在第一位，因為說穿了我們是做服務的，只有服務好了我們的客戶，我們才能很好的生存。所以我們選擇技術架構的第一準則就是高效易用，這樣的話我們才能把更多的精力放在用戶的業務上。在企業應用這個范疇，技術是為業務服務的。估計樓主的思考也是基于這樣的角度吧！
  回復  更多評論
  

用了幾次ibatis后果斷放棄hibernate，有那把hibernate用到爐火純青的功夫，我可以用一點時間用ibatis和sql把項目做到一樣很優秀，然后剩下的時間去干點自己的事。  回復  更多評論
  

@steaman
這兩個在用途上就不一樣，一個是半自動，一個是全自動。
hibernate具有pojo，是走在前沿上的。
現在目前我覺得其實用ibatis和hibernate沒有質的變化，等pojo成熟了，兩者就沒有可比性了。  回復  更多評論
  

dsdsdHibernate的十大罪Hibernate的十大罪Hibernate的十大罪,Hibernate的十大罪Hibernate的十大罪Hibernate的十大罪  回復  更多評論
  

hibernate代碼下載：http://www.zuidaima.com/share/search.htm?key=hibernate  回復  更多評論
  

那個xx就是個2B

  回復  更多評論
  

都這么多年了 還能看見這篇文章  回復  更多評論
  

@菜鳥
hibernate優勢之一就是節約開發時間，你把所有的都用jdbc做了之后，如果本身結構合理，那再去干掉jdbc改用hibernate不一定好  回復  更多評論
  

@shinewang
贊一個  回復  更多評論
  

@誒嘿
我也是這么認為的  回復  更多評論
  

現在大家都不用hibernate了。。  回復  更多評論
  

@比
這位同學這樣認為就不對了，沒有什么東西十全十美的，若要追求完美，就要找出缺陷，這里說的是 Hibernate，你針對人就非常可恥了  回復  更多評論
  

路過看看評論，學習了  回復  更多評論
  

新手學習了。。。不過只記得是說明書和指南的區別。。。  回復  更多評論
  

@xx
你用了多長時間了 你能找到這么多的缺點嗎 ？你做的多 那你說說他的優缺點啊！  回復  更多評論
  

@xx
別的不說，最討厭拿“jboss的總裁比你傻嗎”這種大帽子壓人的人。難道比你聰明的人不會犯錯？難道人家大總裁就不會犯錯？你看看柯達諾基亞這么成功的企業都會倒閉，不就是因為人家決策犯錯嘛，憑什么jboss的總裁不能犯錯。什么沒有壞系統，只有笨的人，你說了一大堆，一點實質性的東西都沒說，有本事也跟樓主一樣列出十點來反駁他的十點啊。空口說白話，坐進說天大。  回復  更多評論
  

@熱心網友
我回復一下，我并不是什么框架的擁護者 只是覺得 LZ武斷判斷不是很好。
1. 實體狀態和緩存關聯，持久化不用save，那是因為用了spring，spring又多了一層對hibernate控制的封裝，不是持久化不用save，而是spring不用save，spring封裝了save動作，程序人員看不見了而已，你要手動管理，你看看要不要save

2. lazy load 我反而覺得lazyload是一個非常好的東西,hibernate的本質原理是要保持數據完整性，所有操作都是在保持數據完整性的基礎上才能進行操作。lazy load 把級聯實體拋棄，只取一部分數據，我覺得很好啊。當然有缺點是，程序結束時并不能lazy load，也就是說 lazy load 只能在程序內，return了就全都取出來了。

3. Open Session In View 已經沒多少人用了，老項目在用，新的已經不用了

4. 級聯，這條就純屬扯淡 ， 數據庫范式本身就存在級聯概念，hibernate的級聯就不是只有hibernate有，用sql 不用級聯的么？你的where的語句本質不是級聯么

5. 批量更新與緩存不一致， 讀寫分離 解決這問題 ，非要 大量的讀和少量的寫參和在一起，緩存不一致的問題，敢問你用肉眼能判斷出來是你電腦內存不夠了呢，還是本身緩存有問題。 讀寫分離 解決。

6. 配置繁瑣， 這條也是扯淡的 ，jdbc 寫一大堆sql繁瑣不繁瑣，凡事都是平衡的，得到一些東西必定意味著你要犧牲一些東西，你得到了開發容易，那么好你只能犧牲配置繁瑣。

7. HQL，這條是面相對象惹的禍，其次我個人的看法，不一定準確：如果某人開發了一個產品，大家都喜歡封裝，不讓別人看到，那么hibernate也是，我做好了我就封裝起來，我封裝的代碼要比屌絲程序員寫的好，如果你想研究，那請你學習hibernate的源碼

8. 太都查詢方案，這條也扯淡，這叫靈活，不要太多查詢方案，純吹毛求si

9. N+1次查詢， 這個確實是這樣的，我也比較詬病這個問題

10. 性能問題，這個其實是有爭議的，有人說大型項目用hibernate不行，可是某大型網站用的是hibernate，PV量也不少，也沒見down掉。性能問題確實是仁者見仁智者見智，并且性能問題是個無底洞，沒有最好只有更好，所以這個問題是個公共的問題。

總結：回復者里面有個人說了，沒有失敗的框架設計者，只有失敗的程序員。我是比較贊同的， 框架只要精通，用的好，就可以解決問題，況且，市面上有很多項目是jdbc和hibernate并用的，sql大了就用jdbc，簡單的東西直接用hibernate，一棒子打死，不科學，hibernate存在的時候，好多人都沒學計算機呢，等你學完計算機了，hibernate還存在著。存在即價值，根本沒有標準定義一個東西適合什么，一個東西不適合什么。這些個寫框架的人都是行業里的翹楚，說白了，人家智商拿出來都比正常人多半斤，你考慮的常識問題人家還沒考慮到，那不白混這么多年了。總之，hibernate是一款很實用的框架，盡管有一些使用方法在滿足特定需求的時候是有些冗余，but條條大路通羅馬通羅馬，用hibernate遇到了這個問題，最先想到的不應該是放棄使用hibernate，而是如何在使用hibernate的基礎把這個問題解決了，我敢保證，你使用其他的可能會解決你當前的這個問題，但是肯定會出現其他不是按照你的思路產生的問題，到時候怎么辦，把那個框架再換了，最后使用jdbc，自己又嫌寫sql太麻煩，太多，那就不要寫程序了，歇著不麻煩，還不累。  回復  更多評論
  

@零雨其蒙
你說的不錯Hibernate確實有很多好處，但是這些并不僅是hibernate獨有的或者可以自己實現，那些思想是不錯的，但是煩惱于在沒有必要的時候去運行多余的工作，我只說性能實在太差了！
就比如說我只想返回一個Count(*)，它就給我封裝成一個List,我在解開其！單說沒有連接數據庫之前就創建了好多的對象，還沒有考慮它的分析的過程呢，結束之后還是好多的對象來封裝！
我的內存啊真是心疼啊！
一個復雜的系統必定有很多的任務，很多的線程，只從一次訪問不能看出性能有多差，但是從整體角度看實在是頭疼啊！
我知道用好其并不會出現多少問題，就是性能實在無法接受！
其實一個系統可以理解成在內存中處理數據的方法，hibernate是一個系統，他有的好處就是按照他固定的思維去做一些事情，所以實現了他的優點，但是有利就有弊，達到優點的本身就是一個不聰明的方法！這是必然的過程，如果沒有缺點必定沒有它的優點，如果一個系統優先考慮性能不能用hibernate，如果一個系統只考慮功能那就可以用hibernate！
哥說的有沒有道理呢！  回復  更多評論
  

裝成什么高手  回復  更多評論
  

搜索HIBERNATE的時候，這篇文章在BAIDU排名比較靠前，嚴重誤導新手，建議作者將文章的名字修改一下。  回復  更多評論
  

我是初學者，我想問，到底好不好？  回復  更多評論
  

@ivan_xu

關于 8. 的見解我還是支持lz的，一直就有(“靈活”的很多種實現方案)與(單一的優質方案)的選擇問題，有些人喜歡多而靈活的，有些人喜歡少兒方便的，但是實際就是絕大多數的時候，“多而靈活的方案”只能是給那些“程序研究人員”秀秀知識秀秀技術的，并不實用（他們最終也只會使用其中之一），那么既然如此其它的多種方案的存在除了可以學習還有什么用處呢？
應該說，“大而全的靈活”并不實用，而依據項目需求“小范圍的靈活”是值得提倡的，并不見得多了就一定好，而從互聯網軟件技術的狀況來說，多了實際是一定不好的

只是提一下，這個問題在對比腳本語言php，ruby，python的時候也是分成兩大撥爭論的  回復  更多評論
  

正是因為很多人,覺得復雜易錯,所以放棄學習復雜框架的機會,而去使用簡單易實現的東西,但是程序員不能決定自己將面對什么樣的項目,而當面對一個hibernate可以完美解決問題的時候,恰恰因為你以前的放棄,而要繞很遠的路  回復  更多評論
  

很奇怪為什么到現在才看到這篇文章，是不是現在才被推薦。從來沒用過hibernate，剛剛開始學，對于樓主的觀點不做評價。就我的經歷來說，每一個公司都有一套自己的技術架構，我做過的項目最少的幾萬，多的幾千萬，都只用了SSH中的一部分技術。也許開發時架構師，項目經理都很厲害，但是項目組里的人技術都能達到那個水平嗎？就算有幾個大牛在監督指導著，但是不要忘了，維護才是大頭，伴隨軟件的一生，大牛也可能會離職的，你能保證后面的每一個程序員都很懂這些？如果后來人看不懂你的代碼怎么辦？
我認為技術要以簡單易用為主，20%的功能就能滿足80%的業務，核心復雜沒關系，但你總要考慮到后面做維護的可能只是一個剛畢業的新人，項目經理也也不可能抓所有的問題，  回復  更多評論
  

作者真是膚淺，一看就是混的幾年經驗！！！  回復  更多評論
  

因為太多的招聘里面的要求有hibernate，所以太多的培訓機構里必有hibernate。總得用個復雜的東西，來顯示逼格，這是花半天就能用上的ibatis具備不了的  回復  更多評論
  

@james_xu
你開發的項目里總會碰見一些初級程序員，你自己不也是從初級程序員過來的，難道你剛出道就是高級程序員，任何框架技術都是用的牛牛的？  回復  更多評論
  

路過路過  回復  更多評論
  

呵呵，真是搞笑 ，作者無知，回復者跟風，我只想說明幾點：
1，目前orm映射成為了建表的主流，不論java，還是新起的nodejs，sailsjs框架，都是如此，關于表名，沒有統一化，我只想說，難道你不會用注解（注解下面再談），按照作者的意思，難不成建立了表之后，還要返回數據庫看看表的字段到底是什么樣子的？
2,關于annotation,也成為了主流，不論是spring，springmvc，都提成和引進了annotation，對于大型項目，200多個類，難不成作何要寫200個xml來配置？還要配置關系？
3，關于性能問題，有什么能比的上純正的jdbc呢（單就開發框架而言）？而hibernate真正的封裝了jdbc或者JNDI，而且就查詢語句來看，hibernate用的是外連接形式，最快的查詢莫過如此吧，其他等待作者自己發現。
4，關于為什么使用這么多查詢語言，我想說，有競爭才有進步，hibernate又沒有讓作者精通所有的查詢語言。
5，hibernate對于我來說，是目前接觸過最好，最簡潔，速度最快的框架，相對于我之前用的ibatis，mybatis，ejb等等。如果作者說hibernate不好，請作者詳細的給大家推薦一個比hibernate更好的框架。
6，設計思維造就了現在的框架，框架必定是一個輔助工具，同步式，阻塞式編程早晚會被淘汰。
7，關于作者提到的級聯，lazy load等等，緩存，我想說這些東西查查成為了hibernate相對于其他框架來說的優點，不要覺得代碼復雜能寫，這個框架帶來的優點和便捷遠遠大于了它的苦澀部分。
8，這是給那些跟風者的，仁者見仁智者見智，我不敢說，我說的東西都對，我接觸的東西有多廣泛，但就我開發的這幾年經驗來看，hibernate的確是一個很不錯的選擇。
說者無心，聽者有意，如果有冒犯的地方，希望我們郵箱探討。  回復  更多評論
  

對于第二條我是很贊同的，在三層的web項目中要想使用lazyLoad我自己覺得是很困難的，這么多年過去了（7年），hibernate依然采用openSessionInView的低效方法。lazyLoad就是雞肋。  回復  更多評論
  

陳大大為了噴而噴，噴完還故作謙虛，你是不是感覺很爽？  回復  更多評論
  

現在做的項目里用的Hibernate框架，感覺好繁瑣  回復  更多評論
  

測試  回復  更多評論
  

1、沒什么卵用，因為一個人的時間有限，沒精力學這么多。用什么學什么！
2、Hibernate既然有缺陷，就要避免，但是這些缺陷如果利用的好，其實也算是另一種便捷！  回復  更多評論
  

c++開發人員飄過。我們沒有那么多現成的框架可用，我很奇怪，為啥不自己封裝數據接口，而把神馬hibernate藏在自己的接口之后。不爽直接換掉，或者自己直接操作數據庫。有問題嗎？神馬風險都解決了。  回復  更多評論
  

說明你用得不夠溜  回復  更多評論
  

@andy
其實我很想問你一下寫C＋＋多久？理解4人組的設計模式嗎？不理解那瞎叫喚啥。C＋＋沒啥高大上，我也會。  回復  更多評論
  

真的是服了評論里的有些人了  回復  更多評論
  

只能說，擁護和說hibernate的人，沒  回復  更多評論
  

只能說，擁護和說hibernate好的人，一定沒做過業務相對較復雜的項目，并發高和對性能有要求的項目，用過ibatis的人都會毫不猶豫扔掉hibernate，單從hibernate sql不能優化，多表關聯，n+次查詢就知道它是多么笨重的傻瓜。  回復  更多評論
  

首先要想想為什么要用orm，hibernate已經違背了簡化jdbc操作的初衷，實現了對象和數據庫轉化的全自動，但極大限制了作為一個實現業務的工具本身的靈活性，和犧牲了程序的性能，并且加大了開發和學習時間，從這幾點看，他就完全違背了簡化jdbc的初衷，ibatis才是真正符合簡化jdbc操作并實現對象和數據庫轉化目的的工具。  回復  更多評論
  

作為開發 其實也挺無奈，有時候采用什么技術或框架不一定是開發團隊說了算，也不一定是團隊中技術最牛的人選擇的最好的技術，就是因為總有那么些無知的人盲目跟風，比較客戶 項目負責人，一個無知的要求和決定就把一個項目給搞殘了，對于hibernate 還有就是基本所有IT培訓機構教的都是它，而不是ibatis，從培訓機構出來的新兵也都只認得hibernate，有一定工作資歷的人都知道，培訓機構的老師大多數是什么水平，基本連項目都沒做過，當然教的東西，簡單并快速呈現就行，哪會考慮復雜的業務和后期的維護以及性能等等，等你業務，表結構，功能稍微一動，一堆問題都出來了。  回復  更多評論
  

@bmz
就比如說我只想返回一個Count(*)，它就給我封裝成一個List,我在解開其！

看到這個話，就表示你不太會使用Hibernate。
  回復  更多評論
  

@Ready
是啊，我還是學生，返回一個Count(*)可以封裝成list返回，也可以用uniqueResult()方法返回一個唯一的值，如果不是唯一的值就會報錯。  回復  更多評論
  

樓主的話就比較偏激了，什么Hibernate的十大罪狀，只能說你還不會用Hibernate，當然任何一門技術都不可能是完美，但是自己覺得很難學不好用可以不去學不去用，但不能誤導讀者，任何一個程序員如果不去研究不去鉆研，那你永遠都是一個只會重復操作的程序員。  回復  更多評論
  

最近一直在研究mybatis，我想請問一下那些說mybatis比hibernate好的同志，你們對hibernate又了解多少？我也用了幾年hibernate了，有人說hibernate的sql調優不方便，hql寫不了復雜查詢，mybatis的sql寫在配置文件里面，便于維護，純尼瑪屬于扯淡，誰給你們的勇氣說hibernate不能寫sql的了？有些人稍微用了下hibernate就在那瞎bb，你們了解多少？我也不說hibernate比mybatis好，存在就有他的意義，就說mybatis，我們公司現在用的就是mybatis，每個實體對應一個mapper.xml，那些用力挺mybatis，你們有沒有發現你們項目中有多少重復的代碼？這在一定程度上就以為違反了java的特性之一：“封裝”，如果你們說我改了表結構可以用mbg重新生成下，說這句話的人你永遠也成為不了一個好的開發人員！沒有真正的用過hibernate就別瞎扯，看到這么多人說hibernate各種不好，實在是不理解，hiberante當然有它不好的地方，難道你用一個框架就一定要所有的都用它的嗎？比如說級聯，你不會不用級聯？你用mybatis的時候是怎么用的？復雜hql寫不出來，難道你就不會寫sql？難道你們不知道hibernate也能執行sql？說到底還是自己不會用！就說這么多，發泄下！！！  回復  更多評論