hibernate效率问题要做一个地区的中国电信的oa，今天说到项目架构时，项目经理说不要用hibernate，完后说了一
hibernate效率问题
要做一个地区的中国电信的oa，今天说到项目架构时，项目经理说不要用hibernate，完后说了一堆道理，我没听懂，好像有提到缓存，请问hibernate为什么效率不高呢，听他那意思是要直接用jdbc，jdbc效率高？那为什么还出这种持久层框架呢
[解决办法]
1.hibernate和jdbc主要区别就是，hibernate先检索缓存中的映射对象( 即hibernate操作的是对象)，而jdbc则是直接操作数据库.
2.Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合
3.Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。
还有一点,正确的使用JDBC技术,它的效率一定比hibernate要好,因为hibernate是基于jdbc的技术.
[解决办法]
hibernate 是为了提高了开发人员的开发效率而开发的。
这肯定是以牺牲性能为代价的。这个代价你自己考虑着用咯
[解决办法]
hibernate 是jdbc的一个框架，基于jdbc。hibernate 查询的时候如果有外键的话，它会把这条记录对应的外键记录给查询出来 而你并不需要你的那条对应外键记录。而jdbc的话他只会查询你所需要的记录。不知道楼主有没有做过大型的项目。如果有用hibernate的话，我想你会深有体会的
[解决办法]
单表操作用hib开发效率很高,性能差不了多少。多表用hib，开发效率不晓得，性能大大降低是肯定。大项目一般关联比较多，所以建议不要用hib来处理复杂的业务逻辑。
[解决办法]
楼上各位都发表了不少高见，说说我的一点看法吧：
大家都从应用程序的性能为出发点来评价hibernate,jdbc甚至ejb,jdo等等常见的持久化技术。
直接说孰优孰劣，还是有点片面，应该结合具体应用。
ejb毫无疑问是分布式环境下持久层的首要选择，这是它天然的特性决定了的：EJB就是为了分布式应用提出的解决方案。但正因为分布式环境在常见系统中并不多见（大部分J2EE应用都是intranet,分布式需求很少，而楼主说的OA，更谈不上分布式了），加上分布式环境的系统设计、分布式数据库设计等等异常复杂，而EJB本身又有一定的复杂性，所以现在SSH组合才如此火爆。可以说，在非分布式应用下用EJB是大材小用，是一种浪费。
抛开分布式应用，再来说说jdbc，hibernate，jdo等等。
可以说，jdbc是整个java数据库应用的基石，不管是hibernate,jdo还是其他持久化框架，其最底层都是基于jdbc的。那么说到这里，在各位心底对三种技术/框架已经有了初步的比较了。
jdbc就是程序员直接通过java.sql及javax.sql类库提供的数据库接口与数据库交互,程序员关注一切数据库细节，包括获取并打开连接，启动事务，进行数据库增删改查，提交，关闭连接，还有异常处理。也就是说，程序员不仅要把握业务（这应该是系统的核心），还要去关注最基本的数据库操作。但灵活性非常高，毕竟你可以把sql,存储过程随时随地的嵌入你的代码中。但hibernate就不行了,你所有可以进行的举动都被约束在映射文件的条条框框之内了
hibernate/jdo是什么？网上说的很滥的一句话就“是对jdbc的轻量级封装”，说白了就是一个第三方类库。但是做了很好的封装，完全可配置化的数据库操作(映射文件)，提供了面向对象风格的查询语句(hql)--这很重要，不要忘了java本身是oo的！纯sql语句却不是oo的，是结构化的。相信各位用过hibernate的大侠都体验了再各个关联对象之间随意导航的便利了(user.depart.userset...)吧。至于L1和L2缓存，Lazy等等，这都是hibernate对性能提升的一种机制。
jdo和hibernate类似（我说的是jdo与hibernate的出发点是类似的，技术细节不在讨论之内）。
这样，纯粹从性能角度对比jdbc与hibernate是很片面的。hibernate的初衷并不是提高程序的性能而是简化程序开发流程，让程序员把工作注意力关注在业务处理上---至少hibernate可以不用做异常处理。
回到楼主说你们的经理说hibernate的缓存会带来问题，这只能说没有用好hibernate的缓存，甚至对它的缓存机制停留在模糊认识状态。如果你不在意性能问题，完全可以禁用它的缓存都没问题。
一句话：任何一种技术/框架的出现都是为了解决特定的问题，并非对先前技术的完全颠覆
[解决办法]
[解决办法][解决办法][解决办法]我虽然对hibernate没实际应用经验，但对jdbc有丰富的使用经验，两者的在概念、技术上还是比较清晰的。而且刚好有六年的电信省集中业务支撑系统部分功能模块的开发经历，应该也算是所谓的主流ISV里的老兵。相对于一个地区级的OA其性能要求应该远低于省集中的BOSS，我们经常碰到的一个性能问题就是Db服务器忙死，而App服务器却在休息，这个可能是完全面向数据库的jdbc大量应用的而导致的一个问题吧！另外为什么不把某些简单功能转为hibernate其在人力培训方面消耗较大，毕竟大环境是业务强于技术的原因有关。不过个人觉得这种o/r技术应该是趋势，只是现在还没有一个统一的、可以完全替换jdbc类技术的技术出现而已
[解决办法]确实我也不太喜欢用hibernate。
一般是用完框架后，提炼出其比较好的东西。
然后自己写框架，符合自己逻辑思维习惯。
是自己写的东西，要做优化的时候方便修改。如果是别人的框架，到处找文档，看源码，挺烦的！
项目开发一般刚开始都是做原型，怎么快怎么做。刚开始是不太关注优化方面的，也不知道将来会优化哪个位置。
只有整个项目在你眼里完全清晰，在后期才有能力去知道该怎么优化。
到后期，需要提高效率的，提高效率。需要加缓存的，加缓存。需要分布式负载均衡的，加分布式。得心应手。
[解决办法]如大多数人所说，用好jdbc绝对比hibernate效率好！
比如我每天8个小时内要插入300万条记录，这个记录里有六七个外键，外键关联的表还有一些其他外键，每张表平均有900万条数据要插入
与hibernate操作对象来说，我相信jdbc的效率要高很多！
[解决办法]批量的update\save\delete,hibernate效率要慢很多
用于查询，正如楼上部分同志所说：如果你一次就要查询w级以上的记录，我个人认为你们的业务逻辑有问题。
通常的小数据量(几十条)查询，由于缓存，还是hibernate快一些的，而这正是我们实际中经常用到的。
最后，使用jdbc和hibernate的开发效率还是差很多的。
[解决办法]这个帖子怎么是<精华>呢?搞不懂...
项目管理人员肯定会根据项目需求选择构架的.
可能项目中每天有几亿条数据....像话费单...
用HB有时候不够灵活.呵呵
用原生态的jdbc操作也有优势....
没什么好吵的了!
另外项目管理中,人力资源的限制:每个人水平不同,驾驭hb的能力不同.最后搞的代码乱七八糟.
时间限制什么的...
做项目的目的是成功的完成,成功的实施.人家才不管你用什么技术呢.
[解决办法]我也说一下。。。
上面有人说。。用了hibernate不想回到jdbc。。。我是用了hibernate好想回到jdbc...
而实际我也这样做了。
我是做企业开发的。。表之间的关系很复杂。。一张表关联十几张表。。
先不用效率。。首先我的开发效率都不知道低多少。。。
上面的人说有缓存。。。但试问。成熟点的人开发的系统，，有多少会直接jdbc的？要不自己实现个cache层，要不自己实现个框架？
效率绝对不比hibernate低，而且又不是做产品，又不需要切换数据库的。有必要通用吗？
一个技术的确是解决实际的问题。但是技术还得服务于现实，并不是为了hibernate而hibernate...
