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