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的缓存，甚至对它的缓存机制停留在模糊认识状态。如果你不在意性能问题，完全可以禁用它的缓存都没问题。

一句话：任何一种技术/框架的出现都是为了解决特定的问题，并非对先前技术的完全颠覆
------解决方案--------------------

探讨

引用:
要做一个地区的中国电信的oa，今天说到项目架构时，项目经理说不要用hibernate，完后说了一堆道理，我没听懂，好像有提到缓存，请问hibernate为什么效率不高呢，听他那意思是要直接用jdbc，jdbc效率高？那为什么还出这种持久层框架呢

纯属谬论，你们的项目经理懂java不，
hibernate最大的有点就是延迟加载，避免业务程序直接访问数据库，建设数据库的负载。对于hibernate的二级缓存的运用更是提升了整个系统的缓冲能力，不过要真正用好hibernate，对于系统的架构设计来说要求很高，首先需要充分的了解系统中个业务流程的联系，设计完善的数据模型，构建表直接正确的关系，这样才能保证hibernate在映射的时候，级联缓冲、操作的正确性，其次如果要使用hibernate的二级缓存，必须先对其hibernate的缓存机制有很好的把握。不要光认为能使用session的几个api操作数据库，就了解hibernate。如果项目是第一次运用hibernate，且没有成熟的业务分析，完善的系统框架设计，建议还是不要使用hibernate，毕竟驾驭hibernate还是需要一个时间，起码1-2年后。能对hibernate有个良好的了解就很不错啦

------解决方案--------------------

探讨

楼上各位都发表了不少高见，说说我的一点看法吧：

大家都从应用程序的性能为出发点来评价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就不行了,你所有可以进行的举动都被约束在映射文件的条条框框之内了