shinewang

關(guān)鍵是Java做不出ActiveRecord吧...  回復(fù)  更多評論
  

支持  回復(fù)  更多評論
  

我2004年就不用Hibernate了.  回復(fù)  更多評論
  

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

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

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

本人弄的一個(gè)快速開發(fā)平臺(tái)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  回復(fù)  更多評論
  

寫這篇文章的時(shí)候就知道總會(huì)引起一些爭議，所以寫完后當(dāng)作草稿放了幾個(gè)月了，促使我今天把它發(fā)出來的原因就是最近公司的項(xiàng)目中又有一個(gè)因?yàn)楹鲆昲ibernate自動(dòng)同步而造成的Bug。發(fā)這篇文章也是提醒正在使用Hibernate的開發(fā)者是否存在這方面的疏忽。  回復(fù)  更多評論
  

稍微有點(diǎn)規(guī)模的項(xiàng)目不用Hibenate問題會(huì)更多。  回復(fù)  更多評論
  

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

軟件的發(fā)展歷史也說明了這一點(diǎn)，想起當(dāng)前使用面向過程的方式進(jìn)行程序設(shè)計(jì)，雖然沒有現(xiàn)在面向?qū)ο蟮乃枷脒x進(jìn)，但程序結(jié)構(gòu)很簡單，實(shí)現(xiàn)也很容易，也沒這么多設(shè)計(jì)模式，說起來很省力。而現(xiàn)在的OOP，雖然看似很先進(jìn)，但實(shí)際上大大增加了程序的復(fù)雜度，之所有現(xiàn)在OOP的設(shè)計(jì)思想使程序設(shè)計(jì)更簡單，是因?yàn)槌绦蛞?guī)模的增長已經(jīng)遠(yuǎn)遠(yuǎn)超過了面向過程升級到OOP所增加的復(fù)雜度。  回復(fù)  更多評論
  

LZ 說的有道理，我個(gè)人認(rèn)為 hibernate 適合國外項(xiàng)目的開發(fā)，開發(fā)國內(nèi)的項(xiàng)目用起來比較痛苦。  回復(fù)  更多評論
  

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

@徐堯
在用不代表沒有缺點(diǎn)，看不到現(xiàn)有技術(shù)的缺點(diǎn)就不會(huì)有新技術(shù)的產(chǎn)生。對象關(guān)系映射的模式不止Data Mapper一種，Data Mapper的實(shí)現(xiàn)也不止Hibernate一種，只是在Java領(lǐng)域Hibernate使用的比較廣泛罷了。  回復(fù)  更多評論
  

個(gè)人認(rèn)為這種基于ORM的技術(shù)最好與語言和開發(fā)工具融合，也就是屬于語言或開發(fā)工具的一部分，無縫結(jié)合，這要比framework更容易使用，說實(shí)話，所謂framework，實(shí)際上就是一個(gè)大大的patch，正因?yàn)檎Z言不支持，才會(huì)做成framework來彌補(bǔ)這個(gè)不足，就象AOP，如果語言支持，那誰還會(huì)再實(shí)現(xiàn)一套AOP framework？  回復(fù)  更多評論
  

@銀河使者
趨勢是這樣，云計(jì)算的環(huán)境下就不需要ORM了，而是完全的面向?qū)ο蟮臄?shù)據(jù)訪問  回復(fù)  更多評論
  

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

技術(shù)是拿來用的，不是來比較的。。自己認(rèn)為不好用，那就用別的。。  回復(fù)  更多評論
  

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

@比
你怎么肯定是我不懂，你怎么肯定團(tuán)隊(duì)中的每個(gè)成員都懂Hibernate，看不到技術(shù)的缺陷而盲目使用必然會(huì)給系統(tǒng)帶來風(fēng)險(xiǎn)，只有充分認(rèn)識(shí)到技術(shù)的優(yōu)點(diǎn)、缺點(diǎn)，才能做到在合適的地方正確地應(yīng)用合適的技術(shù)。此外，在產(chǎn)品開發(fā)時(shí)沒有任何借口逃避對易用性地考慮，可以參考我在前面的回復(fù)。  回復(fù)  更多評論
  

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

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

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

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

@keer
支持。真的應(yīng)該直接用JDBC么？

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

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

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

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

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

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

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

關(guān)注口水帖。
shinewang，同意你的觀點(diǎn)，說實(shí)話，除非強(qiáng)制，我更愿意用jdbc來寫，如果說要支持多個(gè)db，我也愿意為此重寫sql。  回復(fù)  更多評論
  

hibernate的唯一作用，就是把簡單的事情搞復(fù)雜。你們都在討論hibernate的缺點(diǎn)，請問，它有優(yōu)點(diǎn)嗎？
  回復(fù)  更多評論
  

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

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

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

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

其實(shí)說來說去就是一個(gè)易用性的問題，有些看上去很易用的設(shè)計(jì)實(shí)際可能存在隱含的風(fēng)險(xiǎn)，如何界定什么是好的易用性，什么是不好的易用性，這個(gè)問題值得大家思考一下  回復(fù)  更多評論
  

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

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

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

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

@shinewang
可能你理解的快速入門指南是Get Started（Reference的第一章，里面的確沒有談及Update），而我認(rèn)為Hibernate Reference就是所說的快速入門指南了。而詳細(xì)說明書則是Hibernate實(shí)戰(zhàn)那本書。閱讀一遍Reference大約只需要3天時(shí)間，因?yàn)橐还膊?0章。
如果數(shù)據(jù)庫，J2EE基礎(chǔ)很差，而且一個(gè)項(xiàng)目的周期只有2個(gè)月，那就不要用Hibernate了，我發(fā)現(xiàn)很多人看了那個(gè)Reference時(shí)說看不懂，很多都是因?yàn)樗BJDBC、事務(wù)隔離級別，數(shù)據(jù)庫范式，和典型的開發(fā)模式都不知道，看不懂就是自然的了。
如果項(xiàng)目周期有兩年，那么花1個(gè)星期把Reference里的內(nèi)容都實(shí)驗(yàn)一遍，應(yīng)該基本不會(huì)出問題的。
如果您有時(shí)間的話，可以寫Hibernate的十大陷阱，我覺得更有益處~~~  回復(fù)  更多評論
  

還有一點(diǎn)，就是學(xué)習(xí)技術(shù)最好不要看中國人寫的圖書，質(zhì)量極差，誤導(dǎo)性極強(qiáng)~~最好的方法是看Reference入門，然后可以看In Action系列~~  回復(fù)  更多評論
  

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

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

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

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

如果一個(gè)團(tuán)隊(duì)，沒有一個(gè)很懂Hibernate的人，卻貿(mào)然使用Hibernate，這本身就是風(fēng)險(xiǎn)管理的失敗；
并且團(tuán)隊(duì)中的成員又不是很強(qiáng)（因?yàn)楦呤纸M成的團(tuán)隊(duì)，即使之前不懂Hibernate，但是他精通SQL，精通數(shù)據(jù)庫建模，精通JDBC，精通J2EE，現(xiàn)學(xué)也還是會(huì)很厲害），還搞個(gè)新技術(shù)去做，那么風(fēng)險(xiǎn)管理做的就太糟糕了。

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


  回復(fù)  更多評論
  

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

@開源之星

你那400W的項(xiàng)目拿個(gè)出來給大家參考一下!或者一些常用的編程方式發(fā)布給我們看看!

要不然說個(gè)名稱也行!  回復(fù)  更多評論
  

有見地。  回復(fù)  更多評論
  

400w包方便面  回復(fù)  更多評論
  

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

用了幾次ibatis后果斷放棄hibernate，有那把hibernate用到爐火純青的功夫，我可以用一點(diǎn)時(shí)間用ibatis和sql把項(xiàng)目做到一樣很優(yōu)秀，然后剩下的時(shí)間去干點(diǎn)自己的事。  回復(fù)  更多評論
  

@steaman
這兩個(gè)在用途上就不一樣，一個(gè)是半自動(dòng)，一個(gè)是全自動(dòng)。
hibernate具有pojo，是走在前沿上的。
現(xiàn)在目前我覺得其實(shí)用ibatis和hibernate沒有質(zhì)的變化，等pojo成熟了，兩者就沒有可比性了。  回復(fù)  更多評論
  

dsdsdHibernate的十大罪Hibernate的十大罪Hibernate的十大罪,Hibernate的十大罪Hibernate的十大罪Hibernate的十大罪  回復(fù)  更多評論
  

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

那個(gè)xx就是個(gè)2B

  回復(fù)  更多評論
  

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

@菜鳥
hibernate優(yōu)勢之一就是節(jié)約開發(fā)時(shí)間，你把所有的都用jdbc做了之后，如果本身結(jié)構(gòu)合理，那再去干掉jdbc改用hibernate不一定好  回復(fù)  更多評論
  

@shinewang
贊一個(gè)  回復(fù)  更多評論
  

@誒嘿
我也是這么認(rèn)為的  回復(fù)  更多評論
  

現(xiàn)在大家都不用hibernate了。。  回復(fù)  更多評論
  

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

路過看看評論，學(xué)習(xí)了  回復(fù)  更多評論
  

新手學(xué)習(xí)了。。。不過只記得是說明書和指南的區(qū)別。。。  回復(fù)  更多評論
  

@xx
你用了多長時(shí)間了 你能找到這么多的缺點(diǎn)嗎 ？你做的多 那你說說他的優(yōu)缺點(diǎn)啊！  回復(fù)  更多評論
  

@xx
別的不說，最討厭拿“jboss的總裁比你傻嗎”這種大帽子壓人的人。難道比你聰明的人不會(huì)犯錯(cuò)？難道人家大總裁就不會(huì)犯錯(cuò)？你看看柯達(dá)諾基亞這么成功的企業(yè)都會(huì)倒閉，不就是因?yàn)槿思覜Q策犯錯(cuò)嘛，憑什么jboss的總裁不能犯錯(cuò)。什么沒有壞系統(tǒng)，只有笨的人，你說了一大堆，一點(diǎn)實(shí)質(zhì)性的東西都沒說，有本事也跟樓主一樣列出十點(diǎn)來反駁他的十點(diǎn)啊。空口說白話，坐進(jìn)說天大。  回復(fù)  更多評論
  

@熱心網(wǎng)友
我回復(fù)一下，我并不是什么框架的擁護(hù)者 只是覺得 LZ武斷判斷不是很好。
1. 實(shí)體狀態(tài)和緩存關(guān)聯(lián)，持久化不用save，那是因?yàn)橛昧藄pring，spring又多了一層對hibernate控制的封裝，不是持久化不用save，而是spring不用save，spring封裝了save動(dòng)作，程序人員看不見了而已，你要手動(dòng)管理，你看看要不要save

2. lazy load 我反而覺得lazyload是一個(gè)非常好的東西,hibernate的本質(zhì)原理是要保持?jǐn)?shù)據(jù)完整性，所有操作都是在保持?jǐn)?shù)據(jù)完整性的基礎(chǔ)上才能進(jìn)行操作。lazy load 把級聯(lián)實(shí)體拋棄，只取一部分?jǐn)?shù)據(jù)，我覺得很好啊。當(dāng)然有缺點(diǎn)是，程序結(jié)束時(shí)并不能lazy load，也就是說 lazy load 只能在程序內(nèi)，return了就全都取出來了。

3. Open Session In View 已經(jīng)沒多少人用了，老項(xiàng)目在用，新的已經(jīng)不用了

4. 級聯(lián)，這條就純屬扯淡 ， 數(shù)據(jù)庫范式本身就存在級聯(lián)概念，hibernate的級聯(lián)就不是只有hibernate有，用sql 不用級聯(lián)的么？你的where的語句本質(zhì)不是級聯(lián)么

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

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

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

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

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

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

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

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

裝成什么高手  回復(fù)  更多評論
  

搜索HIBERNATE的時(shí)候，這篇文章在BAIDU排名比較靠前，嚴(yán)重誤導(dǎo)新手，建議作者將文章的名字修改一下。  回復(fù)  更多評論
  

我是初學(xué)者，我想問，到底好不好？  回復(fù)  更多評論
  

@ivan_xu

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

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

正是因?yàn)楹芏嗳?覺得復(fù)雜易錯(cuò),所以放棄學(xué)習(xí)復(fù)雜框架的機(jī)會(huì),而去使用簡單易實(shí)現(xiàn)的東西,但是程序員不能決定自己將面對什么樣的項(xiàng)目,而當(dāng)面對一個(gè)hibernate可以完美解決問題的時(shí)候,恰恰因?yàn)槟阋郧暗姆艞?而要繞很遠(yuǎn)的路  回復(fù)  更多評論
  

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

作者真是膚淺，一看就是混的幾年經(jīng)驗(yàn)！！！  回復(fù)  更多評論
  

因?yàn)樘嗟恼衅咐锩娴囊笥衕ibernate，所以太多的培訓(xùn)機(jī)構(gòu)里必有hibernate。總得用個(gè)復(fù)雜的東西，來顯示逼格，這是花半天就能用上的ibatis具備不了的  回復(fù)  更多評論
  

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

路過路過  回復(fù)  更多評論
  

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

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

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

現(xiàn)在做的項(xiàng)目里用的Hibernate框架，感覺好繁瑣  回復(fù)  更多評論
  

測試  回復(fù)  更多評論
  

1、沒什么卵用，因?yàn)橐粋€(gè)人的時(shí)間有限，沒精力學(xué)這么多。用什么學(xué)什么！
2、Hibernate既然有缺陷，就要避免，但是這些缺陷如果利用的好，其實(shí)也算是另一種便捷！  回復(fù)  更多評論
  

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

說明你用得不夠溜  回復(fù)  更多評論
  

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

真的是服了評論里的有些人了  回復(fù)  更多評論
  

只能說，擁護(hù)和說hibernate的人，沒  回復(fù)  更多評論
  

只能說，擁護(hù)和說hibernate好的人，一定沒做過業(yè)務(wù)相對較復(fù)雜的項(xiàng)目，并發(fā)高和對性能有要求的項(xiàng)目，用過ibatis的人都會(huì)毫不猶豫扔掉hibernate，單從hibernate sql不能優(yōu)化，多表關(guān)聯(lián)，n+次查詢就知道它是多么笨重的傻瓜。  回復(fù)  更多評論
  

首先要想想為什么要用orm，hibernate已經(jīng)違背了簡化jdbc操作的初衷，實(shí)現(xiàn)了對象和數(shù)據(jù)庫轉(zhuǎn)化的全自動(dòng)，但極大限制了作為一個(gè)實(shí)現(xiàn)業(yè)務(wù)的工具本身的靈活性，和犧牲了程序的性能，并且加大了開發(fā)和學(xué)習(xí)時(shí)間，從這幾點(diǎn)看，他就完全違背了簡化jdbc的初衷，ibatis才是真正符合簡化jdbc操作并實(shí)現(xiàn)對象和數(shù)據(jù)庫轉(zhuǎn)化目的的工具。  回復(fù)  更多評論
  

作為開發(fā) 其實(shí)也挺無奈，有時(shí)候采用什么技術(shù)或框架不一定是開發(fā)團(tuán)隊(duì)說了算，也不一定是團(tuán)隊(duì)中技術(shù)最牛的人選擇的最好的技術(shù)，就是因?yàn)榭傆心敲葱o知的人盲目跟風(fēng)，比較客戶 項(xiàng)目負(fù)責(zé)人，一個(gè)無知的要求和決定就把一個(gè)項(xiàng)目給搞殘了，對于hibernate 還有就是基本所有IT培訓(xùn)機(jī)構(gòu)教的都是它，而不是ibatis，從培訓(xùn)機(jī)構(gòu)出來的新兵也都只認(rèn)得hibernate，有一定工作資歷的人都知道，培訓(xùn)機(jī)構(gòu)的老師大多數(shù)是什么水平，基本連項(xiàng)目都沒做過，當(dāng)然教的東西，簡單并快速呈現(xiàn)就行，哪會(huì)考慮復(fù)雜的業(yè)務(wù)和后期的維護(hù)以及性能等等，等你業(yè)務(wù)，表結(jié)構(gòu)，功能稍微一動(dòng)，一堆問題都出來了。  回復(fù)  更多評論
  

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

看到這個(gè)話，就表示你不太會(huì)使用Hibernate。
  回復(fù)  更多評論
  

@Ready
是啊，我還是學(xué)生，返回一個(gè)Count(*)可以封裝成list返回，也可以用uniqueResult()方法返回一個(gè)唯一的值，如果不是唯一的值就會(huì)報(bào)錯(cuò)。  回復(fù)  更多評論
  

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

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