不选或许有千万种理由，但是选择hibernate只需要一个理由就足够了

选择一门新技术，首先要看这门技术是否能够满足目前应用的需求，我们承认任何事物都不会十分完美的同时，也在不断追求着能够为本身应用带来巨大价值的途径。

简单来说，就是因为我们很懒，所以我们会一直寻找能帮我们减轻工作量的东西。

因此，hibernate才能被社区广泛接受，这些团队选用hibernate到底是因为什么原因呢？

1.hibernate是一个orm框架，可以自动完成object和关系数据库之间的转换，加速开发。

  这一点就是hibernate最大的特色，不管以前有没有玩过jdbc，看到了hibernate的hello world演示之后估计没有不赞叹的：“操作数据库怎么可能这么简单，hibernate简直是从火星来的哦。”

2.hibernate可以跨数据库。

  这一点其实是实现了orm的后遗症，为了实现一个通用orm，就必须兼容主流的数据库，如果hibernate只能在某一个数据库上跑。那它肯定不会有目前的成就。

  结果这一点就变成了很多产品开发的基础，这些产品只需要关注自己的业务，不需要考虑在不同的数据库之间进行迁移了，一切底层都交给hibernate，只做好自己擅长的事情，花最少的时间获得最大的价值。

3.hibernate上面附着了一大堆的扩展，hibernate-validator可以做数据校验，hibernate-search可以玩全文检索，hibernate-shard可以做水平分表。

  随着不断的发展，hibernate俨然已经发展出一套产品线了，似乎我们只要选择了hibernate，就很容易获得上面说到得这些额外功能，那么到底是自己从头搞起比较爽呢？还是借助社区的力量比较容易呢？一般人还是会选择站在巨人的肩头的，如果所有人都喜欢自己玩，那开源社区也不会这么火了。

毫不脸红的夸完之后，下面是hibernate的问题：

1.封装严重，不容易理解底层实现，导致出现了问题不容易排查。

  这个确实无可奈何，它做的太复杂了，但是纵观orm系列，openjpa之类的jar包大小也是在2m左右，这也就说明orm本身是复杂的，选用orm就意味着要负担它的复杂性，如果不愿意付出学习成本，还是选用更简单的实现比较好。简单实现意味着无法满足上述的优点，正所谓鱼与熊掌不可兼得，大家要在实际选型过程中仔细权衡才行。

2.有些人认为hibernate效率极其低下，无法应付庞大数据量的操作。

  众所周知的情况是，系统的瓶颈往往会出现在数据库一端，因为我们可以搞20几台web服务器集群，但是加db server却不是那么容易的，一般都要经过水平分表才能实现这类需求。

  而对于这种特种应用，说是用hibernate完成关键环节显然是笑话，咱们也不用多说了，还是采用专用的技术去搞定。

  反过来，hibernate是否可以应对一般的应用呢？答案是肯定的，因为hibernate仅仅是在jdbc上进行的封装，只是自动处理了数据类型转换，并对每次操作都实现批量处理，相对一般的程序员来说， hibernate所实现的批量处理显然更高一些，与其让那些对数据库一知半解的人去写sql，反倒不如直接用hibernate还来的方便。


一家之言，万望各位指教

评论

56 楼 sealan 2010-03-25  

难道DBA就不会去学学Hibernate吗

55 楼 iaimstar 2010-03-24  

额。。lz在拿hibernate抢分啊，比抢钱都容易

选不选hibernate ，不是一个群体的观点完全不一样，基本就不可能谁说服谁

54 楼 anky_end 2010-03-24  

Allen 写道

ORM的一个重大意义就在于——程序员可以用操作一个对象的感觉去操作数据库，这样更加接近人本身的思维模式。

某种程度上来说，这也算是降低了学习成本吧。

当然了，现在.NET在推动的LINQ又是另外一种思路了……

学习成本这个不认同。。。
实际来说，hibernate学习成本要高很多。

优势不在于此。

53 楼 iooyoo 2010-03-24  

很可惜，楼主说的优点几乎用不到

用hibernate主要是考虑数据库的封装

52 楼 Allen 2010-03-24  

ORM的一个重大意义就在于——程序员可以用操作一个对象的感觉去操作数据库，这样更加接近人本身的思维模式。

某种程度上来说，这也算是降低了学习成本吧。

当然了，现在.NET在推动的LINQ又是另外一种思路了……

51 楼 抛出异常的爱 2010-03-24  

xyz20003 写道

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

完全是在锻炼项目经理的神经。
没有大象一样的神精。
我可不想在源代码层找自己写出来的bug

50 楼 miaow 2010-03-24  

xyz20003 写道

终于见到一个对sql调优有经验的人，请问，传统sql调优有哪些主要方法，这些方法的效果如何，ORM是如何将这些SQL调优方法都阻碍了呢？

我觉得，只有了解了SQL调优的传统方法，才能进行比较得出ORM之上的解决方案，之前所见的人都是空对空，只知道说ORM性能有问题，却没有给出SQL调优的解决之道。抓住一个点进行具体分析，才适合搞技术的。

个人感觉，没什么必要过于强调sql调优的问题吧。
正常讲，应该对会生成什么sql大概有数。
除非是很简单的用法，一般用了hql也应该关注生成的sql是什么，看有没有“超常”的sql出现。
复杂到想不出来的，个人感觉一般除了报表不多。
报表大家是不是也“特事特办”？

49 楼 miaow 2010-03-24  

上个帖子是针对贫血模型。
充血模型可能有所不同，但没在实际项目中用过，说不好影响。
哪位折腾过的讲讲？

48 楼 miaow 2010-03-24  

hatedance 写道

非常赞同，我一开始也是用hibernate来存取pojo，甚至连外键都不配。后来学习了DDD和spring，才明白，是hibernate和spring让DDD成为可能。有了hibernate，我觉得DAO层都是多余，因为DAO这个名字就是过程化的概念，应该直接把hibernate作为Object Repository。

调存储过程和偶尔配置SQL查询的时候用用DAO没啥不好吧。

即使一般的存取，我觉得也有必要再加一个类，这层只是简单的调用hibernate。
业务层捆死hibernate个人认为还是不太好。只是几行代码和配置的事。

47 楼 xyz20003 2010-03-23  

刃之舞 写道

xyz20003 写道

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

你的介绍中对hibernate的优点其实都是缺点，而介绍的缺点确是绝对致命的可以让人完全不会去选择的。

有足够的了解你得能说的出来，茶壶煮饺子只会糟蹋饺子

我不喜欢你这种讨论问题的方式，一味的批评，而不提出任何建设性意见，很容易误导其他人。虽然你的比喻非常生动形象，但是让其他人看了稀里糊涂，完全搞不明白你所批判的是什么东西。

如果hibernate提高开发效率和跨数据库都是缺点的话，至少应该稍微说明一下这些缺点会导致哪些后果，给其他人一些警示，而不是空口白话的说：“你就是缺点，你就是错了。”这样对人对己都没有什么益处。

我非常欢迎出现反对的意见，但希望这些反对意见是建立在事实的基础上，而不是臆断出来的。

期待您对上述内容进行补充，帮助大家了解hibernate的缺点，感激不尽。

46 楼 刃之舞 2010-03-23  

xyz20003 写道

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

你的介绍中对hibernate的优点其实都是缺点，而介绍的缺点确是绝对致命的可以让人完全不会去选择的。

有足够的了解你得能说的出来，茶壶煮饺子只会糟蹋饺子

45 楼 linliangyi2007 2010-03-22  

xyz20003 写道

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

达人的思想和见识令我佩服，是应该都往这个方向去努力才是啊！！

44 楼 xyz20003 2010-03-22  

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

43 楼 lf84730258 2010-03-22  

lf84730258 写道

大部分认同吧,我的观点是,中国的企业都很烦躁= =.越小的企业越烦躁.很多这针对框架的问题.其实不难解决,可是我们没时间解决,没时间等待那个高手,或者身边没有这样的社区,JAVA说实在的没有一项技术是真正开源的.都和大家说开源,开源不是开放源代码就叫开源.你要让别人用的技术能解决与其相关的问题,才叫开源,对于代码开源这种框架有等于没有,只有既有专业的教程,系统的学习文档的开源框架才是真正的开源.开源而不解决大家的迷惑.这种东西,别人用Hibernate 不能解决现在当前特定环境下的问题的时候,会说这个框架差也是很正常的.
  现在JAVA开源＝复杂封装＝难以学习＝用老技术能解决的问题,用新技术,到处是异常到处问到处浪费时间还解决不了.最后搞自己信心崩溃.成熟的东西,无论Hibernate还是什么技术,国内现在最应该做的就是让大大们把这些框架的每一个技术点,应用都写出来.虽然这种东西很难做到.但是,还是抱着这种想法,我绝对不是那种希望窃取别人劳动果实的人.我只希望让这个框架真正的成熟开源起来.而不是这种不伦不类的开源

这一点我不太赞成，很多人都希望直接把开源软件拿来解决业务问题，这种想法有点儿偏差。

其中最大的问题是：“开源只是一种分布开发方式。开源并不包含商业运作。”

开源就是一群人在很专业的玩某一领域的技术，这就导致了开源搞出的东西很专，在某一方面可能很好用，但是想把它作为一套完整的解决方案就捉襟见肘了。光靠开源社区就可以搞出一套完整的解决方案，无所不包，拿来就用？现在看来是完全不可能的，自己的问题还需要自己花功夫解决。

开源社区会帮你完成一定程度上的对接集成，但是诸如：“客户想要这个东西很灵活，满足他们的所有需求”这种东西靠开源来实现，太不现实了。你是在为甲方定做一套系统，满足甲方的实际需求，甲方没有遵循一套规范，你怎么可能在社区里找到完美的解决方案呢？

  我并非是想找完美的解决方案,而是想从实际角度出发去看待这个框架.就像我之前学习Hibernate我可以说我学的很用心,到了实际开发的时候.我才发现原生SQL 原来封装对象与HQL不一样,更别说学习到的2级缓存这些东西了.在学习的时候,demo小,考虑的少.实际问题一出,怎么用都无头绪.我只想那些高手,能从实际的角度.将Hierbnate的一些细节功能拓展开来讲.
  还有就是,不是要完美解决方案,那种东西,不可能那么容易找到.我不知道JAVAEYE是否做到了,一个异常如果我去百度.或者GOOGLE,要么就是到处复制.搞的到处解决方案一样,不过很多都是不匹配的.而JAVAEYE的思想不就是为了帮助大家更好学习交流的一个比较好的平台么.那么大可以把关于某块的异常曾今解决过的问题帖子,集中一起,也好.可能javaeye 已经做到了,只是我没注意.我是希望能最块的检索到我想要的信息.如果别人解决,我找帖子也块,没人帮忙一个人去解决问题的事.做太多了.好累.

42 楼 icewubin 2010-03-22  

slaser 写道

我觉得LZ应该修改下标题，针对的是ORM技术，而不是hibernate工具。
现在得hibernate不光可以做orm,也直接支持运行sql语句和存储过程，用hibernate甚至可以不用其ORM部分，也可以获得很多好处。
我就有个项目，只用hibernate管理和运行sql语句，sql语句全部在配置文件里面，我想DBA肯定很喜欢。

顶，支持。

hibernate本身就有足够的灵活性，可以根据不同模块的业务特点，某些部分用OO的特点，某些部分直接用sql。

41 楼 icewubin 2010-03-22  

xyz20003 写道

novembersky 写道

用了orm，sql调优是个大问题，甚至一些传统的诊断调优方法都没办法用了。比如oracle费尽心思历经数个大版本建立起来的一套自动优化SQL执行计划的算法CBO，如果用了orm，那这些就意义寥寥了。

终于见到一个对sql调优有经验的人，请问，传统sql调优有哪些主要方法，这些方法的效果如何，ORM是如何将这些SQL调优方法都阻碍了呢？

我觉得，只有了解了SQL调优的传统方法，才能进行比较得出ORM之上的解决方案，之前所见的人都是空对空，只知道说ORM性能有问题，却没有给出SQL调优的解决之道。抓住一个点进行具体分析，才适合搞技术的。

那得有一定的限定条件才能讨论，例如novembersky举的例子的前提就是提到了数据库要用Oracle。

如果理解成，某个项目的主结构采用面向数据的设计，这种设计可以是和ORM没什么关系的。ORM的起源和这种设计方式没什么关系。

但是反过来说，不能否定其他设计方式采用ORM的整体技术方案。

各种方案都有其优缺点，没有前提的空对空是没有什么太大的意思。

40 楼 slaser 2010-03-22  

我觉得LZ应该修改下标题，针对的是ORM技术，而不是hibernate工具。
现在得hibernate不光可以做orm,也直接支持运行sql语句和存储过程，用hibernate甚至可以不用其ORM部分，也可以获得很多好处。
我就有个项目，只用hibernate管理和运行sql语句，sql语句全部在配置文件里面，我想DBA肯定很喜欢。

39 楼 xyz20003 2010-03-22  

novembersky 写道

用了orm，sql调优是个大问题，甚至一些传统的诊断调优方法都没办法用了。比如oracle费尽心思历经数个大版本建立起来的一套自动优化SQL执行计划的算法CBO，如果用了orm，那这些就意义寥寥了。

终于见到一个对sql调优有经验的人，请问，传统sql调优有哪些主要方法，这些方法的效果如何，ORM是如何将这些SQL调优方法都阻碍了呢？

我觉得，只有了解了SQL调优的传统方法，才能进行比较得出ORM之上的解决方案，之前所见的人都是空对空，只知道说ORM性能有问题，却没有给出SQL调优的解决之道。抓住一个点进行具体分析，才适合搞技术的。

38 楼 novembersky 2010-03-22  

用了orm，sql调优是个大问题，甚至一些传统的诊断调优方法都没办法用了。比如oracle费尽心思历经数个大版本建立起来的一套自动优化SQL执行计划的算法CBO，如果用了orm，那这些就意义寥寥了。

37 楼 sky.zha 2010-03-22  

该jdbc就jdbc，该hiberntate就hibernate