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会给你更多痛苦的