Goingmm

真不敢想象,如此的ORM框架,僅只有一位核心程序員(也不知道是真還是假).作為對JDBC的輕量級的對象封裝,hibernate確實有很多優點,這里相信大家都比我清楚,但是缺點也不是沒有,比如批量操作,我要指出一點點不足,hibernate的映射生成工具不是很好用(至少幾個月前是這樣, 不知道現在有不有成熟點的),不管是hibernate自帶的那個叫什么dll2hbm,還是xdoclet,或則eclipse插件形式的生成工具,都會根據不同的情況出現不同的問題,出現問題的唯一辦法就只有手工改配置文件.
  回復  更多評論
  

回復人名字可以隨便寫，也可以冒充別人，所以沒有必要用真名字。

為什么要用　Hibernate ？

我只覺得增加了學習時間，等哪天我精通了　Hibernate ，Hibernate 又過時了。

  回復  更多評論
  

Hibernate 比 CMP 好在哪里？  回復  更多評論
  

對頭，先想為什么要用，再講如何用。  回復  更多評論
  

crud還是很有用的

但對hql還不是很滿意

hbm和pojo最好手工改, 自動化工具無法勝任, 特別是已經在運行的項目  回復  更多評論
  

Re:
2005-11-04 10:13 | Water Ye@ITO
hbm和pojo最好手工改, 自動化工具無法勝任, 特別是已經在運行的項目


手工改容易弄出很多新Bug出來，特別是已經在運行項目。
如果已經使用了EJB，只是用Hibernate來做持久層，最后還是需要在容器內測試，享受不到輕量級系統的好處。
  回復  更多評論
  

都裸起，我也裸露一盤，goingmm不介意吧？
轉摘一篇《Hibernate的優點 》：

一、Hibernate是JDBC的輕量級的對象封裝，它是一個獨立的對象持久層框架，和App Server，和EJB沒有什么必然的聯系。Hibernate可以用在任何JDBC可以使用的場合，例如Java應用程序的數據庫訪問代碼，DAO接口的實現類，甚至可以是BMP里面的訪問數據庫的代碼。從這個意義上來說，Hibernate和EB不是一個范疇的東西，也不存在非此即彼的關系。

二、Hibernate是一個和JDBC密切關聯的框架，所以Hibernate的兼容性和JDBC驅動，和數據庫都有一定的關系，但是和使用它的Java程序，和App Server沒有任何關系，也不存在兼容性問題。

三、Hibernate不能用來直接和Entity Bean做對比，只有放在整個J2EE項目的框架中才能比較。并且即使是放在軟件整體框架中來看，Hibernate也是做為JDBC的替代者出現的，而不是Entity Bean的替代者出現的，讓我再列一次我已經列n次的框架結構：

傳統的架構：
1) Session Bean <-> Entity Bean <-> DB
為了解決性能障礙的替代架構：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate來提高上面架構的開發效率的架構：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3個架構來分析：
1、內存消耗：采用JDBC的架構2無疑是最省內存的，Hibernate的架構3次之，EB的架構1最差。

2、運行效率：如果JDBC的代碼寫的非常優化，那么JDBC架構運行效率最高，但是實際項目中，這一點幾乎做不到，這需要程序員非常精通JDBC，運用Batch語句，調整PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的情況下采用結果集cache等等。而一般情況下程序員是做不到這一點的。因此Hibernate架構表現出最快的運行效率。EB的架構效率會差的很遠。

3、開發效率：在有JBuilder的支持下以及簡單的項目，EB架構開發效率最高，JDBC次之，Hibernate最差。但是在大的項目，特別是持久層關系映射很復雜的情況下，Hibernate效率高的驚人，JDBC次之，而EB架構很可能會失敗。

4、分布式，安全檢查，集群，負載均衡的支持
由于有SB做為Facade，3個架構沒有區別。

四、EB和Hibernate學習難度在哪里？

EB的難度在哪里？不在復雜的XML配置文件上，而在于EB運用稍微不慎，就有嚴重的性能障礙。所以難在你需要學習很多EJB設計模式來避開性能問題，需要學習App Server和EB的配置來優化EB的運行效率。做EB的開發工作，程序員的大部分精力都被放到了EB的性能問題上了，反而沒有更多的精力關注本身就主要投入精力去考慮的對象持久層的設計上來。

Hibernate難在哪里？不在Hibernate本身的復雜，實際上Hibernate非常的簡單，難在Hibernate太靈活了。

當你用EB來實現持久層的時候，你會發現EB實在是太笨拙了，笨拙到你根本沒有什么可以選擇的余地，所以你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮選擇哪個方案，因為只有唯一的方案擺在你面前，你只能這么做，沒得選擇。

Hibernate相反，它太靈活了，相同的問題，你至少可以設計出十幾種方案來解決，所以特別的犯難，究竟用這個，還是用那個呢？這些方案之間到底有什么區別呢？他們的運行原理有什么不同？運行效率哪個比較好？光是主鍵生成，就有七八種方案供你選擇，你為難不為難？集合屬性可以用Set，可以用List，還可以用Bag，到底哪個效率高，你為難不為難？查詢可以用iterator，可以用list，哪個好，有什么區別？你為難不為難？復合主鍵你可以直接在hbm里面配置，也可以自定義CustomerType，哪種比較好些？你為難不為難？對于一個表，你可以選擇單一映射一個對象，也可以映射成父子對象，還可以映射成兩個1:1的對象，在什么情況下用哪種方案比較好，你為難不為難？

這個列表可以一直開列下去，直到你不想再看下去為止。當你面前擺著無數的眼花繚亂的方案的時候，你會覺得幸福呢？還是悲哀呢？如果你是一個負責的程序員，那么你一定會仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，你會覺得你已經陷入進去拔不出來了。如果是用EB，你第一秒種就已經做出了決定，根本沒得選擇，比如說集合屬性，你只能用Collection，如果是Hibernate，你會在Bag，List和Set之間來回猶豫不決，甚至搞不清楚的話，程序都沒有辦法寫。


  回復  更多評論
  

“還是沒的名字的”? 建議樓上的兄弟還是留下一個別名吧!!
Re: 為什么要用Hibernate ？ 我只覺得增加了學習時間，等哪天我精通了　Hibernate ，Hibernate 又過時了。
個人想法：學習是看自己的興趣了，如果對這個感興趣才會去學習。我不建議完全沒有興趣，純粹為了做項目去學習。這樣效果也不會很好。在這里，我不愿意去做一個技術的布道者。只希望盡量能在使用以后，用平常心去討論

Re:Hibernate 比 CMP 好在哪里？
這個問題我也沒有深入的去研究過。列出幾個供大家參考吧！
1） CMP要求所有的訪問操作都在事務環境中，非事務方式的訪問不受支持。提出了一個全新的事務模型（method-based descriptor)。hibernate沒有試圖創造一個更新的模式，相反，Hibernate沿用了傳統數據庫的Transaction編程模式。
2） 繼承是對真實對象建模時常用的概念，但CMP并不支持它。CMP在組件的定義和實現時并不一致，在具體實現一個EntityBean接口時，實現的類可以具有繼承關系，但在定義這個EntityBean時卻不行。類之間的關系也只是在接口之間，而不是在實現類之間，因此這些關系也不存在多態性
3） CMP雖然也有Local接口，但是Web層還是需要通過Remote接口訪問EJB層的數據,序列化、網絡調用、創建大量的對象，都是性能降低的原因
4） CMP很難實現動態Query，這是因為它基于代碼自動生成技術，即最終的執行代碼是在部署編譯時生成的。hibernate則有根本的改變，它基于reflection機制，運行時動態Query是很自然的事。另外，hibernate幾乎支持所有的SQL語法。

  回復  更多評論
  

我的名字就先叫“沒的名字的”

我贊成用hibernate不用復雜的JDBC的方法（雖然我用JDBC比用hibernate要快，我就是上次參加那個不準說名字的項目用了一下hibernate，現在都忘記了）。

關于性能問題：
用CMP的時候，只是做查詢慢。
但是可以用JDBC來做查詢啊。用JDBC只做查詢應該不復雜吧？沒有必要用hibernate了。
還有就是使用SessionFacade做門面，CMP根本不需要遠程接口。
EJB2.1規范允許把無狀態的Session Bean弄成WebService，既然要效率，還做什么WebService？ 傳輸XML是比較慢的。

不知道什么時候計算機的性能會才會因為達到了物理極限而不能再提高了，也許到了那個時候又有新技術變為現實了，比如量子計算機。  回復  更多評論
  

用JDBC做查詢有個缺點，就是程序員可能會忘記關閉打開的數據庫連接。

在開發程序的時候，可以在AppServer里設置連接池的最大連接數為1，強迫程序記住關閉連接，不然查了一次就不能查第二次了。  回復  更多評論
  

上面是“強迫程序員記住關閉連接”，是程序員不是程序，少打了一個字。  回復  更多評論
  

上面的上面的上面我說“用CMP的時候，只是做查詢慢”。
現在要更正一下，是“做查詢返回大量結果的時候慢”。

還有就是用CMP做查詢返回大量結果的時候，只能返回Collection的問題。用JDBC也能返回其它類型，比hibernate還要靈活。


  回復  更多評論
  

呵呵~~ 匯編也很好，但是不見得有很多人用

不否認JDBC的優點。但是眼下J2EE項目開發，我們現在的選擇還會是JDBC嗎？  回復  更多評論
  

我是說如果只做查詢的話，可以用JDBC，沒有必要用hibernate了。

用hibernate會更麻煩。


用JDBC只是用來解決CMP的致命問題。


具體就是做只讀的DAO，用Session Bean來調用DAO。  回復  更多評論
  

Hibernate的查詢SQL經過優化處理。估計用JDBC沒有點功力的也寫不出來。還有他可以減少很多無謂的數據庫交互。他能緩存下查詢的記錄。各種方式支持你自由配置。當然你也可以自己去實現這些功能。但這基本上是沒有必要的

我們還是不要再無謂的爭論這個拉，我發覺這里離題已經越來越遠了。呵呵！  回復  更多評論
  

我知道你們現在一起住的三個人有兩個都參加過上次那個不準說項目的真名字的那個用 Session Bean + hibernate 的項目。

我更喜歡用CMP，雖然我沒有在大項目中實踐過。

你慢慢猜我是哪個哈。  回復  更多評論
  

1) 知道我們現在在北京住一起的三個人，肯定是一個比較樂觀開朗的人，關心時事
2) 知道我們參與過并不能說出項目真實名字，那么一定是中國人，而且參加過這個項目
3) 你的刷新頻率這么快，而且出沒這么孤獨。現在一定不在CTU-SDC，并且新加坡Office不能打開我的這個blog。
4) 有連續三次回帖補充的記錄。你的年齡不會超過25歲
我還是記不起來。記得上一次聽人說喜歡CMP還是去年，一個很牛B的架構師[name is secret]。All men like CMP he saied 。可能碰巧給你聽見了，呵呵！~~~愿意的話，就把你的名字告訴大家吧，我們不要再浪費blogjava的硬盤空間了。本來就很珍貴的。  回復  更多評論
  

goingmm，你在搞偵察所，“天黑請閉眼……”  回復  更多評論
  

看見你在那里亂分析我是誰，我回家了都忍不住要回復你。

我就是那個平時喜歡一個人玩，被報表項目浪費了一大半青春的6山酒林。

我忘記了Hibernate，還沒學會SQL Map，連iHis我也快忘完了。  回復  更多評論
  

6山酒林是啥子喲？  回復  更多評論
  

真是的，測試一哈  回復  更多評論