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


一家之言，万望各位指教

评论

96 楼 skcmm 2011-03-18  

使用开源框架、从中学习人家的OO对象与数据库操作的思想，让程序员更多专注于业务 解决普遍性问题 才是初衷

95 楼 田耕信息技术 2011-02-28  

yawei 写道

elmar 写道

xyz20003 写道

外边随处可见的产品宣传“采用了hibernate，可以运行在目前所有的主流数据库上。”试想一下，如果自己开发一套基于数据库存储的产品，是选择自己实现兼容所有数据库呢？还是用hibernate？

我会选择只使用最标准的sql而不会用hibernate。

right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.

Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.

After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.

At this point, you realize this is just another F**KING ORM.

使用框架，能快速解决某方面的问题，但同时也给别方面造成更大的困难。它可能在这方面灵活了，但在别一方面却显得笨拙。在这方面开发有效率了，但在另一方面却是负担。

94 楼 田耕信息技术 2011-02-28  

yawei 写道

elmar 写道

xyz20003 写道

外边随处可见的产品宣传“采用了hibernate，可以运行在目前所有的主流数据库上。”试想一下，如果自己开发一套基于数据库存储的产品，是选择自己实现兼容所有数据库呢？还是用hibernate？

我会选择只使用最标准的sql而不会用hibernate。

right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.

Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.

After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.

At this point, you realize this is just another F**KING ORM.

没用过Habernate，只知道最基本的功能就是ORM。不过我个人喜欢用SQL语句来解决执行效率问题，而Habernate是解决开发效率问题，这两者还是有不小差异的。

另外，跨数据库的问题，在金融电信等领域，别说跨数据库，连数据库的版本号及其所在的LINUX主机环境都不敢动，一个小小的配置都可能导致灾难性的后果。所以说Habernate与跨数据库放在一起作为它的优点，这恐怕绝对不是原作者的本意，而是一些软件开发者宣传自己产品卖点的一种策略。实际应用中，大多数是些无关紧要的数据库才要考虑移植。

真正的跨数据库，我看还是多从标准SQL语句方面入手吧。

93 楼 yawei 2011-02-01  

elmar 写道

xyz20003 写道

外边随处可见的产品宣传“采用了hibernate，可以运行在目前所有的主流数据库上。”试想一下，如果自己开发一套基于数据库存储的产品，是选择自己实现兼容所有数据库呢？还是用hibernate？

我会选择只使用最标准的sql而不会用hibernate。

right. so you create severl util class to build sql query from pojo(or class, or whatever holds data) , it works well.

Then you find some databases have really nice feature you want to use, so you implements profiles for those databases.

After everything, you put your utils and db profiles into a jar and want to reuse it in your next project.

At this point, you realize this is just another F**KING ORM.

92 楼 elmar 2011-01-30  

xyz20003 写道

外边随处可见的产品宣传“采用了hibernate，可以运行在目前所有的主流数据库上。”试想一下，如果自己开发一套基于数据库存储的产品，是选择自己实现兼容所有数据库呢？还是用hibernate？

我会选择只使用最标准的sql而不会用hibernate。

91 楼 ppgunjack 2011-01-29  

跨数据库是种理想而已，经历的几个产品都做到了操作系统可移植，唯独数据库不能动
Hibernate要能算可靠的跨数据库方案，那jdbc都能算了，衡量可用性不是存取数据就完事了
企业用户关心的就是数据，至于oo，ssh，可移植客户关心吗？只有打单的乙方关心
开源的实现又不承担升级后对api的冲击和客户支持
企业应用还是商业db为王，商业中间件次之，然后是服务器厂商，看看几个最重要的开源现在都握在那些厂商手里，都是数据库厂商
与其强求dba学hibernate，不如要求程序员多学学数据库更合理。dba是管整个数据系统安危可靠，干嘛为了程序员的dao的选型又学java又学hibernate？
不要指望把扩缩依赖orm，应该更多考虑orm是否影响扩缩方案

90 楼 DOCDOC 2011-01-29  

ppgunjack 写道

adaikiss 写道

javazeke 写道

有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。

如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......

大的项目别说换数据库，数据库版本都不会动，连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市，带来的OS和主机升级会立项成立项目组专门进行移植和测试

现在系统自己实现了类似规则引擎的东西，问为啥不用jrule或者drools一类的成型的东西，曰，那时还没什么人用java
也找不到这些

企业级的产品，Linux这种背景尚且花了这么长时间，不要说其他的东西，如果用hibernate能降低很大成本的，说明原来成本本就不大

这要看情况了，如果你只是做个旧项目的outsource, 那自然不需要考虑跨数据库。

89 楼 ppgunjack 2011-01-28  

adaikiss 写道

javazeke 写道

有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。

如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......

大的项目别说换数据库，数据库版本都不会动，连着固定配置的主机和固定版本的OS一起打包
如果因为主机退市，带来的OS和主机升级会立项成立项目组专门进行移植和测试

现在系统自己实现了类似规则引擎的东西，问为啥不用jrule或者drools一类的成型的东西，曰，那时还没什么人用java
也找不到这些

企业级的产品，Linux这种背景尚且花了这么长时间，不要说其他的东西，如果用hibernate能降低很大成本的，说明原来成本本就不大

88 楼 supben 2011-01-28  

哥们，你用了top
还想让hibernate帮你跨数据库？

87 楼 DOCDOC 2011-01-28  

adaikiss 写道

javazeke 写道

有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。

如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......

如果基于自己的解决方案平台给客户做项目，多数据库的适应性还是非常非常重要的。

86 楼 adaikiss 2011-01-28  

javazeke 写道

有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。

如果你的项目是只卖给一个客户当然不需要, 但是如果你的产品是卖给不同用户的, 而你的用户又不愿意重新购买一个数据库......

85 楼 woshihlp 2010-05-04  

学习了。。
心得：
做大项目，开发的团队大，用hibernate+反范式设计的数据库可从各方面保障开发效率，但是测试起来得谨慎了。。。
然后hibernate的多数据库支持，真换数据库了可不像说的那么轻松，要看做的功能用的HQL语句是不是大多不用改。。。

84 楼 ssuupv 2010-04-30  

aguai0 写道

哥们的头像挺有个性的

说我的吗？

83 楼 icewubin 2010-04-30  

ssuupv 写道

抛出异常的爱 写道

icewubin 写道

anky_end 写道

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

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

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

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

到plsql有时不准，同时一条语句，同样数据量，在生产环境中有时运行700-30000MS之间不等。差别相当的大。

生产环境会受OS和db的缓存的影响的。

82 楼 抛出异常的爱 2010-04-30  

ssuupv 写道

抛出异常的爱 写道

icewubin 写道

anky_end 写道

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

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

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

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

到plsql有时不准，同时一条语句，同样数据量，在生产环境中有时运行700-30000MS之间不等。差别相当的大。

plsql不准的话。。。。
loadrunner吧
个人认为loadrunner有点重。

81 楼 aguai0 2010-04-30  

哥们的头像挺有个性的

80 楼 ssuupv 2010-04-30  

HIB性能优化办法。其实跟JDBC性能优化办法。基本过程是
1.客户投诉慢
2.根据投诉慢功能点，查到性能问题代码点（其中这点蛮难的。我们一般都是客户说慢了，我们才去到指定代码跟踪。在开发环境不容易被发现）
3，针对问题点，如果是sql的语句。或者数据库一些设置问题。如果是数据库设置问题我想HIB跟JDBC区别不大吧，如果是sql语句。我想会HIB的人。基本上能控制HIB写的代码。转换出来的SQL是什么样，优化HIB代码也是比较容易的。所以HIB一般性能优化是没有问题。

其实HIB性能不好，还是不能直接调用数据库专属的。有些专属对环境对性能提升比较明显。

最后一点就是HIB表设计，跟JDBC表设计。宗旨是不一样的，有些地方是完全相背的。

79 楼 ssuupv 2010-04-30  

抛出异常的爱 写道

icewubin 写道

anky_end 写道

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

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

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

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

到plsql有时不准，同时一条语句，同样数据量，在生产环境中有时运行700-30000MS之间不等。差别相当的大。

78 楼 hjtracy1 2010-04-26  

个人认为java这种面向对象的高级语言纯粹使用jdbc不太现实。使用orm框架确实能加快开发速度，保证程序员有充足的时间处理业务逻辑而不是底层数据库代码的编写

77 楼 jasonshi 2010-04-22  

myreligion 写道

hibernate其实还有一个不足：对DBA不友好！

严重同意，这玩意简直是抢DBA的饭碗。

用了hibernate，大部分SQL都比较简单，偶尔有复杂的SQL，通常也比普通开发人员写的要好。
做性能优化，可以直接用jprofiler等工具在java端分析，偶尔拿个SQL在PLSQL Developer/TOAD中分析一下执行计划。
我们公司，用hibernate的项目，遇到性能优化都是开发人员顶上，而那些大量用PLSQL的项目，通常需要DBA全程参与优化