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


一家之言，万望各位指教

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

一点就够了
何况两点.

不同层次的人，对hibernate的看法不在同一个层面上。
仅此而已。

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

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

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

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

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




项目基本不会换数据库。

产品就不一样了，简单来看jbpm吧，它本身关注的是流程引擎，数据库对它来说，只是为了持久化数据用的，如果不使用hibernate，它就要自己写sql脚本去适应不同的数据库，有了hibernate以后，它的作者就只需要关注引擎内部的实现了。

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

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

开源软件并不是你所想象的对于真实业务逻辑做一个大而全的实现，就算是大而全的实现也会因为应用场景的不同而不能很好的适应新的需求！按照你的理解，非开源的软件做出来的东西就可以拿来就用？不用做Enhance，不用作二次开发就可以适应不同客户的需求？我看这样的项目还从来没有诞生过！

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

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

开源软件和商用软件之间的区别在于商用软件是由实际的需求驱动产生，所以它具有明确的目的性和应用范围，为开源软件大多源于解决某一个问题或者有某位天才的灵光一下而产生，所以不要指望开源软件给你提供一个完全切合你的需求的解决方案，相对商用软件，开源软件应该更多的给人的启迪是分享的精神和创新的意识

一家之言，得罪，请评判！