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


一家之言，万望各位指教

评论

36 楼 20055294 2010-03-22  

至今 还不怎么懂 这个东西

35 楼 anky_end 2010-03-22  

产品化的项目，hibernate的优势太大。

不过hibernate的缺点其实也摆在那边，hql并不简单，也不轻松。对复杂查询支持不算好；性能调试和问题排查非高手不能办。

对于习惯sql的程序员来说，debug出来奇怪的sql难以阅读

34 楼 passionke 2010-03-21  

hibernate 我觉得理念是做的非常好的
弄过面向对象编程的人 虽然还有面向过程的手段
但是怎么也不愿意回头到C编程时代了

33 楼 hatedance 2010-03-21  

linliangyi2007 写道

gdpglc 写道

我觉得 hibernate 还有一个很关键的用处，也是ORM框加的重要用处，帮助程序使用面向对象的方法来表达业务逻辑。而这正是hibernate的根本所在。不理解面向对象的人，理解hibernate是有困难的。如果只把对象作为库表内容的包装，这是一种肤浅的看法。hibernate要做的是使得业务逻辑的表达只要关注对象就可以了，而对象和数据库的关系，则由hibernate来维护。在理想状态下，业务逻辑可以不考虑数据库的访问（当然现实是做不到的），这就使得面象对象的思想得以实现。

只有有了这种关念，才能把握好 对象和库表的关系，尤其是对象间关系和库表间关系的差异和对应，才能理解hiberante的种种行为。只会用hibernate存取一个POJO，用面向过程的思维来理解hibernate这叫 暴殄天物

+1 ,

楼主 和 楼上这位同学的观点都很到位

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

32 楼 linux1689 2010-03-21  

关于Hibernate，还是等我出一本书来从底层原理上来提高用户对它的认识吧。

31 楼 former 2010-03-20  

选合适的产品解决适合的问题。很多人在说这个那个框架的时候，像是在玩田忌赛马，人无完人，jar无完jar……
hibernate上升到这样的高度，对选择他的企业、项目来讲，不必要重新发明轮子、有大量的文档可查、有牛人可以被请来培训，有可用的程序员可以招揽。
hibernate的配套设施越来越全，我们在annotations、validator做扩展，就可以满足项目对于这两方面的业务需要，提高效率。
数据库我们倒是不常换，而且偶尔有些本地化的sql没法通用。
楼上同学说的OO思想极为赞同！

30 楼 yin_bp 2010-03-20  

icewubin 写道

linliangyi2007 写道

gdpglc 写道

我觉得 hibernate 还有一个很关键的用处，也是ORM框加的重要用处，帮助程序使用面向对象的方法来表达业务逻辑。而这正是hibernate的根本所在。不理解面向对象的人，理解hibernate是有困难的。如果只把对象作为库表内容的包装，这是一种肤浅的看法。hibernate要做的是使得业务逻辑的表达只要关注对象就可以了，而对象和数据库的关系，则由hibernate来维护。在理想状态下，业务逻辑可以不考虑数据库的访问（当然现实是做不到的），这就使得面象对象的思想得以实现。

只有有了这种关念，才能把握好 对象和库表的关系，尤其是对象间关系和库表间关系的差异和对应，才能理解hiberante的种种行为。只会用hibernate存取一个POJO，用面向过程的思维来理解hibernate这叫 暴殄天物

+1 ,

楼主 和 楼上这位同学的观点都很到位

建议大家看看领域驱动设计，还有马丁的几本老书，再来看Hibernate的设计，就知道hibernate的价值所在，以及设计成这样的原因了。

当然对hibernate了解到一定程度，完全可以跳出框框，只用你需要的部分，没必要用全hibernate中的所有功能啊。

可否参考一下bbossgroups开源项目的持久层框架，bbossgroups包含一下子项目：
1.bboss-persistent, a persistent framework.
参考bbossgroups框架来实现持久层的操作：
a.灵活的事务管理（声明式事务管理，可编程事务管理，java注解事务管理，jdbctemplate事务管理，五种经典的事务类型，支持事务嵌套，支持多数据库分布式事务）
b.灵活的访问数据库的接口（普通sql操作，预编译sql操作，普通/预编译批处理操作，存储过程，函数）
c.一套经典的数据库操作标签库（增删改查，普通sql操作，预编译sql操作，普通/预编译批处理操作）
d.经典的多数据库连接池配置管理和使用方法（所有的数据库操作接口可以直接指定连接池的名称，方便地实现对不同数据库的操作）
e.提供了简单的o/r mapping查询接口
f.提供了多种行处理器来提升查询操作的性能
g.可以方便地实现blob，clob字段的处理
h.提供分页操作接口（预编译和普通），可以方便地址各种数据库的分页操作
2.bboss-taglib, a web layer taglib framework(list tag,pageine list tag,detail tag ,logic tag,tree tag,tabpane tag,dbutil tag).
3.bboss-aop, an aop framework.(ioc ,rpc[jms,mina,jgroups,cxf webservice],bean component,cxf webservice component framworkset and so on).
4.bboss-event, an event framework(local event,remote distribute event framework base aop rpc framework).
5.bboss-util, an utility framework.
6.antbuildall, ant build project that build up projects.
7.bbossevent-client, an event remote client test project.
8.bboss-client, an rpc client test project.(jms,mina,jgroups,cxf webservice，restful).
9.bboss-ws, bboss webserive framework test project.
10.bbossgroups document 目录包含framework 开发文档和bboss aop框架的技术使用文档

bboss group project blog:
http://blog.csdn.net/yin_bp
http://yin-bp.iteye.com/

bboss group project sourceforge site url:
http://sourceforge.net/projects/bboss/files/

从bbossgroup 1.0开始，已经将以前的持久层框架，aop框架，标签库框架，事件框架，工具框架，全部作为bbossgroup 的子项目一起发布
新增antbuildall [ant complile for all bboss group projects],可以运行antbuildall下的run.bat命令编译所有的子项目，并且更新相应工程
的引用jars。


release version : bbossgroups-1.0
release date: 2010/03/18
release files:Contain all sub projects source files,distribute files,All projects dependended jars,So the file size is some bigger,do not warry,every sub project can be downloaded alone.

bbossgroups 最新版本 1.0，整合了原来所有的子项目（持久层框架，标签库框架，aop框架，事件框架），下载地址：
https://sourceforge.net/projects/bboss/files/
hibernate确实不适合用来做大型项目的持久层工具，建议参考一下bbossgroups框架来实现持久层的操作：
1.灵活的事务管理（声明式事务管理，可编程事务管理，java注解事务管理，jdbctemplate事务管理，五种经典的事务类型，支持事务嵌套，支持多数据库分布式事务）
2.灵活的访问数据库的接口（普通sql操作，预编译sql操作，普通/预编译批处理操作，存储过程，函数）
3.一套经典的数据库操作标签库（增删改查，普通sql操作，预编译sql操作，普通/预编译批处理操作）
4.经典的多数据库连接池配置管理和使用方法（所有的数据库操作接口可以直接指定连接池的名称，方便地实现对不同数据库的操作）

5.提供了简单的o/r mapping查询接口
6.提供了多种行处理器来提升查询操作的性能
7.可以方便地实现blob，clob字段的处理
8.提供分页操作接口（预编译和普通），可以方便地址各种数据库的分页操作


bbossgroups 最新版本 1.0，整合了原来所有的子项目（持久层框架，标签库框架，aop框架，事件框架），下载地址：
https://sourceforge.net/projects/bboss/files/
持久层框架子项目下载地址：
http://sourceforge.net/projects/bboss/files/bbossgroups-1.0/bboss-persistent.zip/download

29 楼 icewubin 2010-03-20  

linliangyi2007 写道

gdpglc 写道

我觉得 hibernate 还有一个很关键的用处，也是ORM框加的重要用处，帮助程序使用面向对象的方法来表达业务逻辑。而这正是hibernate的根本所在。不理解面向对象的人，理解hibernate是有困难的。如果只把对象作为库表内容的包装，这是一种肤浅的看法。hibernate要做的是使得业务逻辑的表达只要关注对象就可以了，而对象和数据库的关系，则由hibernate来维护。在理想状态下，业务逻辑可以不考虑数据库的访问（当然现实是做不到的），这就使得面象对象的思想得以实现。

只有有了这种关念，才能把握好 对象和库表的关系，尤其是对象间关系和库表间关系的差异和对应，才能理解hiberante的种种行为。只会用hibernate存取一个POJO，用面向过程的思维来理解hibernate这叫 暴殄天物

+1 ,

楼主 和 楼上这位同学的观点都很到位

建议大家看看领域驱动设计，还有马丁的几本老书，再来看Hibernate的设计，就知道hibernate的价值所在，以及设计成这样的原因了。

当然对hibernate了解到一定程度，完全可以跳出框框，只用你需要的部分，没必要用全hibernate中的所有功能啊。

28 楼 amonlei 2010-03-20  

ps: 一下 hibernate的跨数据库其实不是100%跨，只能说80~90%跨，比如有些数据库不支持 top 这个关键字，hql里面写了就很郁闷了

27 楼 jili 2010-03-20  

脱离项目特性来谈论一个技术框架，似乎有点飘忽吧？
如果项目的特征是业务模型复杂，业务逻辑难度高（比如一些企业应用），那么hibernate可以让你的实现模型更贴近业务模型和分析模型，可以让你更关注于业务本身。
如果项目特征是大数据量，高性能要求，那么hibernate未必是最适合的选择。
还是那句话，没有银弹。关键需求和关键特性决定技术选型。

26 楼 刃之舞 2010-03-20  

没觉出用hibernate会比用jdbc增加多少开发效率，
一个连jdbc都不会用的人开发人员让他用hibernate开发绝对是噩梦，
一个连sql都写不好的让他写hql更是大噩梦

25 楼 Jwind 2010-03-19  

aabcc 写道

javazeke 写道

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

产品化的项目经常要根据客户的情况更换数据库

不一定大才要换...

换数据库？我们连数据库的版本都不敢换。
但是hibernate确实比较方便。

24 楼 lxf9501 2010-03-19  

用spring jdbc template的飘过

23 楼 yangjim 2010-03-19  

skydream 写道

分享一下我们目前的做法，简单的说就是两条腿走路：

1. 对于性能敏感的地方，使用spring jdbc template
2. 对于性能不大敏感的地方，使用hibernate

一直觉得技术没有绝对的好与不好，关键在于用的地方是否合适。

hibernate对jdbcTemplate也是支持的。有些地方habernate执行效率低的话，就改用jdbc。

22 楼 zhanghaocool 2010-03-19  

这么说jdo也很好哇，也能加速开发(没有HQL不知道快不快..)，比hibernate更能跨数据库，而且还是一种规范，不喜欢这家实现可以换那家

21 楼 firewood 2010-03-19  

在做过的许多项目中 大多是阉割过的hibernate 使用hibernate各种关系的话 程序员对业务跟hibernate必须相当的理解 否则将加大开发跟维护难度
当然单纯的单表操作hibernate是优于jdbc的

20 楼 aabcc 2010-03-19  

javazeke 写道

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

产品化的项目经常要根据客户的情况更换数据库

不一定大才要换...

19 楼 firewood 2010-03-19  

不可否认 hibernate的实现机制 使得它在批量修改 删除操作时 性能相对jdbc是下降的

18 楼 skydream 2010-03-19  

分享一下我们目前的做法，简单的说就是两条腿走路：

1. 对于性能敏感的地方，使用spring jdbc template
2. 对于性能不大敏感的地方，使用hibernate

一直觉得技术没有绝对的好与不好，关键在于用的地方是否合适。

17 楼 tianhaoleng 2010-03-19  

不要把关注点总放在什么性能啊，跨数据库上好不。

hibernate出现的唯一目的就是解决面向对象编程和关系数据库之间的阻抗。

使用hibernate你只需要考虑一点：

我这个软件设计是采用面向对象设计还是数据库思维设计。

如果是前者，就应该使用hibernate.