不选或许有千万种理由，但是选择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还来的方便。


一家之言，万望各位指教

评论

76 楼 fjlyxx 2010-04-21  

看应用场景吧，你总不能把Hibernate用在数据整合的系统里面吧，基于数据库的简单应用倒是不错的，不过数据挖掘和分析的应用这个不太适合吧。 我也同意楼上的看法，生产系统、业务系统谁都会做，SSH派还真是不少，但是很多SSH派一离开SSH就不会写系统了， 不知道是开发人员的杯具还是框架的杯具。个人觉得打好基础，用什么框架都好商量，框架只是一个辅助的东西不能作为技术的根本。认认真真的打基础SSH自然会懂，JAVA的框架不少但就我接触的框架来看都没有离开JAVA最根本的几个技术基础和设计理念。

75 楼 icewubin 2010-04-06  

抛出异常的爱 写道

icewubin 写道

抛出异常的爱 写道

icewubin 写道

anky_end 写道

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

利用工具很容易打出每一句执行的时间。

别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。

你说的这个是发现慢的时候，再把sql复制过去。

我的意思是，测试的时候打出来，顺便就能做第一次的过滤，如果发现执行很快就不用复制到plsql中去了。

没有需求，不关客户体验。。。。你优化它干什么？

这不算是优化呢，是防止团队中某些人写出不合理的hql（sql）程序而已，如果在测试环境某些sql执行的时间就很慢，那就更别提生产环境了。（不过这里的慢没有界定范围，多少秒或多少毫秒算慢）

74 楼 抛出异常的爱 2010-04-06  

icewubin 写道

抛出异常的爱 写道

icewubin 写道

anky_end 写道

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

利用工具很容易打出每一句执行的时间。

别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。

你说的这个是发现慢的时候，再把sql复制过去。

我的意思是，测试的时候打出来，顺便就能做第一次的过滤，如果发现执行很快就不用复制到plsql中去了。

没有需求，不关客户体验。。。。你优化它干什么？

73 楼 vaivxuanzi 2010-04-06  

最关键是客户用得爽 》 给钱 》老板 》发钱 》我们    <br/>
你程序性能再好 用了多么先进的技术 客户不喜欢  你的程序一样 over

72 楼 vaivxuanzi 2010-04-06  

其实我觉得老板觉得可以就好  什么速度慢之类的可以抛到一边去了  再慢也不会慢10秒8秒的吧  最多也就1、2秒的时间  客户又不会拿着秒表对着你的程序 看哪个慢哪个快 

71 楼 icewubin 2010-03-25  

抛出异常的爱 写道

icewubin 写道

anky_end 写道

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

利用工具很容易打出每一句执行的时间。

别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。

你说的这个是发现慢的时候，再把sql复制过去。

我的意思是，测试的时候打出来，顺便就能做第一次的过滤，如果发现执行很快就不用复制到plsql中去了。

70 楼 抛出异常的爱 2010-03-25  

icewubin 写道

anky_end 写道

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

利用工具很容易打出每一句执行的时间。

别没事找事。。。。。
没毛病自找麻烦。
直接到plsql时去看运行效率。。。。

69 楼 icewubin 2010-03-25  

anky_end 写道

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

利用工具很容易打出每一句执行的时间。

68 楼 icewubin 2010-03-25  

anky_end 写道

icewubin 写道

我的意思是，ibatis开发过程中如何和DBA沟通，hibernate也是一样的，开发人员当然是和DBA讨论sql，不可能让dba去学hql。

（当然这里隐含的条件是，开发人员对sql必须要有基本的掌握）

就性能再说，增删改，就是单条sql，数据量大这个是dba负责分析的东东。
只要阐述业务逻辑即可，不需要把sql打印出来

优化的地方在于复杂查询，我认为这方面hibernate没什么优势，或者用ibatis或者jdbc直接上。

倒是n+1查询等等造成的性能问题，需要j2ee端人员对hibernate要掌握精深才行

1.对于部分复杂查询，hibernate直接用sql也是超简单的。

2.你这样说话是误导别人，只要对hibernate的查询部分、数据抓取策略研究一下即可，谈不上什么掌握精深。

3.我们公司用ibatis，照样天天有新人写出N+1的程序来。

67 楼 miaow 2010-03-25  

找慢的sql先找DBA去抓DB中情况分析，个人经验。

66 楼 anky_end 2010-03-25  

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

65 楼 anky_end 2010-03-25  

icewubin 写道

我的意思是，ibatis开发过程中如何和DBA沟通，hibernate也是一样的，开发人员当然是和DBA讨论sql，不可能让dba去学hql。

（当然这里隐含的条件是，开发人员对sql必须要有基本的掌握）

就性能再说，增删改，就是单条sql，数据量大这个是dba负责分析的东东。
只要阐述业务逻辑即可，不需要把sql打印出来

优化的地方在于复杂查询，我认为这方面hibernate没什么优势，或者用ibatis或者jdbc直接上。

倒是n+1查询等等造成的性能问题，需要j2ee端人员对hibernate要掌握精深才行

64 楼 icewubin 2010-03-25  

我的意思是，ibatis开发过程中如何和DBA沟通，hibernate也是一样的，开发人员当然是和DBA讨论sql，不可能让dba去学hql。

（当然这里隐含的条件是，开发人员对sql必须要有基本的掌握）

63 楼 miaow 2010-03-25  

俺不能同意你更多 ;p

62 楼 icewubin 2010-03-25  

miaow 写道

打sql这招数我们也玩。
沟通出问题的例子：
DBA说看这个sql没多少可优化的，你们搞这个sql是干嘛的，看看能不能换个思路写或者改库表结构来改进。
程序员拿出来，DBA对着类图和hsql中间一堆.就晕掉了。
这种情况，DBA学点hibernate基础会很有帮助。
不用管缓存啊验证啊什么的，知道关联啥意思，能和开发团队交流起来。
可话说回来，要真有hibernate达人，我相信和DBA合作也不会有问题。

1.数据库设计的时候，DBA应该要适当参与评估的。

2.如果某些模块对性能有要求，某些数据抓取的策略是要有人牵头，评估的，这个人可以是开发人员，也可以是架构师，只要有人牵头，一些复杂的数据抓取策略在实现前就先简单沟通一下，就不用等后期出了性能问题再解决。

3.一般来说，数据库设计的时候，是要考虑到数据存入、抓取、更新的策略，这一阶段设计完善的话，后续都是有办法的，这一阶段的设计其实和是否用hibernate没有太大的必然联系，hql最终也是要变成sql的，除非是某些针对性的数据库的特殊sql，一般的通用sql优化策略（例如数据抓取的策略），无论什么orm还是jdbc，这个业务复杂度都是一样的。

4.所以在这种前提下，后期打印出来的sql如果再出问题，就基本上就是由于hibernate使用不当造成的，设计上没问题都好解决。

61 楼 anky_end 2010-03-25  

linliangyi2007 写道

sealan 写道

难道DBA就不会去学学Hibernate吗

这个问题问的好？我见过某些单位的同事，会了SQL就保守的不行了，啥语言都不学了，何况是一个开源啊。

所以说，人的问题是很大的。

看业务方面吧。

比如大量采用新技术的公司，规模不太大的话，需要程序员会的多，未必要精通。

像大型项目的dba，他们要学习的东西也很多很杂，而且其思路已经有所局限，不是不学，而是难有作为。

分工不同罢了。

强求人人会hibernate没什么必要，既然采用hibernate，那么负责j2ee这块的负责人就得有这种觉悟：hibernate不是做不到，而是要学的深入。指望把j2ee该搞定的事情推到dba头上去学习是不负责任的做法

60 楼 miaow 2010-03-25  

打sql这招数我们也玩。
沟通出问题的例子：
DBA说看这个sql没多少可优化的，你们搞这个sql是干嘛的，看看能不能换个思路写或者改库表结构来改进。
程序员拿出来，DBA对着类图和hsql中间一堆.就晕掉了。
这种情况，DBA学点hibernate基础会很有帮助。
不用管缓存啊验证啊什么的，知道关联啥意思，能和开发团队交流起来。
可话说回来，要真有hibernate达人，我相信和DBA合作也不会有问题。

59 楼 icewubin 2010-03-25  

miaow 写道

DBA学点hibernate基础对交流协作有好处，但不能把架构师的任务推给DBA啊。

办法是人想出来的，例如DBA不懂HQL，我知道有一家公司就是这样协调的，测试的时候有工具可以很方便的把所有测试时产生的sql打印出来，去重后，DBA一目了然，看起来也是很方便的。

58 楼 miaow 2010-03-25  

DBA学点hibernate基础对交流协作有好处，但不能把架构师的任务推给DBA啊。

57 楼 linliangyi2007 2010-03-25  

sealan 写道

难道DBA就不会去学学Hibernate吗

这个问题问的好？我见过某些单位的同事，会了SQL就保守的不行了，啥语言都不学了，何况是一个开源啊。

所以说，人的问题是很大的。