shinewang

@心夢帆影
正在修改，請等待一周后發布的新版

看上去不錯

轉載也要說明原文出處啊,歡迎訪問我的新博客http://www.eoss.cn/blog/

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

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

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

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

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

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

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

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

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

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

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

@appu
想要覆蓋全部很難，所以說僅供參考，況且實際程序中還要涉及到數據庫等其他瓶頸的影響。The Computer Language Benchmarks Game的測試結果吭一訪問這里http://shootout.alioth.debian.org/

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

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

@robertlyc
多個測試結果顯示目前ruby性能還是比不上python的

@永恒
1.每天讀一遍本文提醒自己
2.改變思維習慣
3.找搭檔彌補自己的不足

@mingj
那么，博主有什么具體的解決方法，那個rails style 的 Java web 應用開發框架開發得怎么樣了

@隔葉黃鶯
不是很清楚你說的<textarea>問題，<textarea>在firefox下也正常啊。ActiveX確實是個問題，主要是國內網銀在用。

@隔葉黃鶯
在blogjava后臺寫文章時，我怎么只能在firefox下才能使用添加連接，ie下不行，在幾臺機器上都這樣

@隔葉黃鶯
suse的界面確實比Ubuntu好

@hcom
正在用Java(JDBC)、Java(Hibernate)、Grails、Rails分別寫一個簡單的論壇，過幾天也把這個Play!論壇例子放一起測一下性能

@太陽里的雪
是的，原文是Powered by Play!
http://www.playframework.org/manual/contents/apps

@太陽里的雪
最新的stable4里面有個SpringPlugin

@daniel
很難說play!和grails究竟哪個風險高。play!雖然還不成熟，但核心代碼很少，幾百K的Java代碼很容易搞清楚和自己擴展。play!的風險主要是它不是建立在spring+hibernate的基礎上，也不能或者說不方便部署在tomcat這類常見的Java服務器上。而grails的風險其實也是不成熟產生的，一方面我們都知道封裝帶來易用性的同時也要付出靈活性的代價，另一方面grails對spring+hibernate的包裝沒有到位，所以導致用spring+hibernate很容易做的，用grails反而難做了。如果play!能夠建立在spring+hibernate的基礎上就完美了。

@rmn190
play!有很多有爭議的特性，例如大量static方法，但仔細想像是符合使用情形的，還有public的成員變量來模擬實現屬性，這個是為了敏捷的變通，而我們一邊收的教育是使用private，但好用就行，把對程序的控制權交回給開發者。

@jeasonzhao
確實是這樣，play!很多地方是另起爐灶的，和現有ssh的經典架構、tomcat等服務器的集成可能不是很方便。目前使用play!最好還是直接使用它那套東西。當然play!也在努力，例如對spring的集成、對其他服務器的支持就在開發中。

呵呵，不好意思，以Note開頭的文章是我作為備忘的，以后有時間再補充的詳細點。

@zhuxing
這篇文章主要是《Beyond Java》幾個要點的摘錄，算是讀書筆記，目前還沒有哪個語言有取代Java的趨勢，雖然比例略有下降，Java依然穩穩的占據編程語言排行榜（TIOBE）的第一位，但編程語言變革的暗潮已經在涌動了，我覺得這幾點可以作為我們把握開發語言發展趨勢的參考。

內容是很短，所以我全文輸出了，即使標題“拉風”，但也沒有搞個摘要把你們騙進來啊。

@IceRao
不過,動態語言性能比較差

@IceRao
是的,ruby就滿足條件1,2,4,對條件3也在加強中,erlang很符合條件5

@s
價錢高和開發效率高是兩回事吧

@6246
能舉個例子嗎？

@6246
事實上正好相反，基于IDE的RAD已經過時，而且好像也不存在nb的ide工具

第９條確實不大好懂，我想應該是這樣的意思：對于各類框架的設計思想、優缺點等已了然在胸，能夠根據不同的環境選擇合適的框架，即使重新實現一個合適框架也不是難事，手中無劍，心中有劍。

Java會給你更多痛苦的