再论hibernate是否适合做大型应用

       开这个帖子，是源于一场javaeyer们的关于hibernate的争论，本来想回帖，但越写越长，干脆开个新贴算了，原帖：http://www.iteye.com/topic/617722 主题：昨天面试一个有5年左右工作经验的人，居然说hibernate不适合做大型项目。

    

      我想对那些说hibernate不适合大型项目的同学说，你扪心自问，你真的了解hibernate吗？
    
      hibernate说到底，无非就是对jdbc做了些封装，屏蔽了不同数据库的特性，加上了一些缓存而已，有多神秘？有多难以掌控？对查询结果和javabean的映射，难道你用jdbc就不用做了吗？有些人对hibernate了解根本不够深入，对hibernate难以足够的掌控，妄言hibernate不适合做大型项目，如果你说它不适合做大型项目，请你说出为什么，而不是一味的指责，我在这里可以逐条的和你细细探讨交流。
 
      有些人了解了一些皮毛就称自己精通ssh框架，然后妄自品论，这样的人我见的太多了，曾经有一个同事，做了一个合同管理模块，对合同表查询几次，jvm就内存溢出了，而且数据库几乎不响应，我经过调试后发现，合同表下有个商品清单表，一个合同有多个商品，每个商品记录有几张图片，这些图片都以base64编码存储在表里了，在查询合同的时候，没有做关联级别的延迟加载，查询合同时，将这些合同下面的所有商品都检索出来了，而实际上当前合同查询根本就不需要显示商品，并且商品里的图片的base64编码都查询出来了，全部放在内存里了，对合同表翻页查询几次后，jvm内存溢出。更要命的是，他配置的spring事物管理有问题，导致每次持久层操作都没有事物管理，并且没有关闭数据库连接，这些原因导致合同模块使用几次后，系统就非常慢。很难想象，如果不是我指出了问题所在，某一天，他登录进javaeye，是不是也理直气壮地说hibernate不适合大型项目，然后后面一群人人云亦云的附和？

 

      还有些人说，如果对数据库不了解，那就别谈深入了解hibernate了，二者有一些联系，对数据库了解得非常深入，那么在使用hibernate时候是如虎添翼，对数据库了解得不深入，不见得就不能很好的利用hibernate，这是充分条件，而非必要条件，如果数据库逻辑设计很糟糕，物理存储上又没有做很好的优化，甚至连索引都没有，那么你用什么orm工具性能都不会好，orm工具不是石头里蹦出来的，最终还不是要靠jdbc来执行，难道你指望hibernate来解决一切？在一个设计优良的数据库上，再谈对hibernate的使用，切莫将数据库的优化和hibernate的合理使用混为一谈。还有些人相反，对数据库的了解仅仅限于增删改查，这样的人太多了，相信大家都会遇到这样的一些人，很难相信这样的人对hibernate又能用得多好，你可能很熟悉hibernate的api，但是你却不清楚它的使用场景以及如何利用数据库的特性，如果一个大表连索引都没有，或者没有一个很好的存储策略，那么你的hibernate延迟加载，缓存做到多么好，也很难提升系统的性能，但是，这个是hibernate的问题吗？

 

       还听到一些人抱怨，hibernate为什么这么弱智？批量操作的时候非要先把记录一条条查询出来，然后再一条条更新或删除，例如批量更新，批量删除，或者有些人根本不知道批量操作是这样做的。这些都跟hibernate的一级缓存有关系，它要保持一级缓存和数据库的数据一致性，如果一下子删除表中大批记录，它不知道如何更新缓存里的对象。批量操作会影响性能，但是完全可以规避它，用原生sql，虽然导致session级别的缓存和数据库的不一致，但是在应用上完全可以规避，这个并不是hibernate设计不好的问题，而是鱼和熊掌不可兼得。

 

       看看作为JAVAEE5的持久层标准的的JPA规范，完全借鉴了hibernate设计思想和检索策略，只是为了不那么露骨，换了些名称而已，如session换成了entitymanager等等，当初jboss也是最早实现了jpa的厂商，因为它有hibernate，在这基础上，加上一些注解，加上一些jpa要求容器实现的部分，很快完成，在2006年的时候就出来了，那个时候，连ejb3的规范都一直在变。如果hibernate不优秀，会被工业标准借鉴吗？

 

       我不是hibernate的狂热崇拜者，我早已过了那个阶段，我要做的是，为hibernate说句公道话。我不是说hibernate一定能适合所有场合，也不是说hibernate是万能的，我想说的是一种做事的态度，对某一个东西发表高见之前，我们应该先对它有一个深入的了解，如果我们都这样做，那么中国it界的浮躁是否也会减少一些？

 

从业很多年，真的感觉有些人脑子很轴，对于那些人感觉没啥可说的，楼主也没必要多废话了，随他们去吧。

技術都是用來配合需求的

千里馬賽馬各有所長

其实问题不是在于Hibernate，而是在于用Hibernate的人。
举个很简单的例子，为啥要有驾照考试？不是说汽车危险，而是开汽车的人如果不懂交通规则，当然会出事故。
所以如果团队中没有对Hibernate有深刻理解和钻研的技术人员的话，那还是先三思一下吧。

各自有各自适用范围，如果hibernate随便什么情况都适用，那ibatis还有存在空间么？JDBC岂不是也都应该会被hibernate取代了

比如常见的多表联合查询，hibernate就算有延迟加载，但是那种先单表批量查出来实体再一条条查明细的方式就很不适合了，当然你可以说写HQL去做，但是都写HQL，那我还要你这ORM干嘛？我不会直接用nativeSQL？难道还要开发人员又学SQL又学HQL？SQL还能让DBA去审去调，HQL写不好又怎么办？那还能起到提高开发效率的目的么？

hibernate拿来处理一下CRUD，利用一下它二级缓存，这也就是它最适合的使用方式了，至于其他的，还是交给SQL去做吧

很无聊的文章~~
任何技术都有适用和不适用的环境。

如果说在任何环境下都要用hibernate，我反对~~
但是如果说在任何环境下都不要用hibernate，我也反对~~

因地制宜~~不要忘记这四个字~

顶起，支持hibernate

数据量巨大，性能要求苛刻的系统，hibernate很难达到要求
所谓的大型项目的很难确定，不知道有多大，但是不需要上面要求的我觉得基本是没问题

技术问题都可以归纳为这点，赞同!

有道理，顶你。