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？说到底还是自己不会用！就说这么多，发泄下！！！  回复  更多评论