jdbc与hibernate的优缺点比较(转载的精髓)
一、 Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口 的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而 不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：传统的架构：
      1) Session Bean <-> Entity Bean <-> DB

为了解决性能障碍的替代架构：

      2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：

     3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：                 

1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。               

2、运行效率： 如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语 句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。 EB的架构效率会差的很远。                  

3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。                  

4、分布式，安全检查，集群，负载均衡的支持 由于有SB做为Facade，3个架构没有区别。四、EB和Hibernate学习难度在哪里？      EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。     



Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。 当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好 坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。Hibernate相反，它太灵活了，相同的问题，你至少可以设 计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是 主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用 iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪 种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较 好，你为难不为难？ 这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员， 那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决 定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞 不清楚的话，程序都没有办法写。补充:

JDBC与Hibernate在性能上相比，JDBC灵活性有优势。而Hibernate在易学性，易用性上有些优势。当用到很多复杂的多表联查和复杂的数据库操作时，JDBC有优势。

相同点：

◆两者都是JAVA的数据库操作中间件。

◆两者对于数据库进行直接操作的对象都不是线程安全的，都需要及时关闭。

◆两者都可以对数据库的更新操作进行显式的事务处理。

不同点：

◆使用的SQL语言不同：JDBC使用的是基于关系型数据库的标准SQL语言，Hibernate使用的是HQL(Hibernate query language)语言

◆操作的对象不同：JDBC操作的是数据，将数据通过SQL语句直接传送到数据库中执行，Hibernate操作的是持久化对象，由底层持久化对象的数据更新到数据库中。

◆数据状态不同：JDBC操作的数据是“瞬时”的，变量的值无法与数据库中的值保持一致，而Hibernate操作的数据是可持久的，即持久化对象的数据属性的值是可以跟数据库中的值保持一致的。

JDBC与Hibernate读取性能

1、JDBC仍然是最快的访问方式，不论是Create还是Read操作，都是JDBC快。

2、Hibernate使用uuid.hex构造主键，性能稍微有点损失，但是不大。

3、Create操作，JDBC在使用批处理的方式下速度比Hibernate快，使用批处理方式耗用JVM内存比不使用批处理方式要多得多。

4、读取数据，Hibernate的Iterator速度非常缓慢，因为他是每次next的时候才去数据库取数据，这一点从观察任务管理器的java进程占用内存的变化也可以看得很清楚，内存是几十K几十K的增加。

5、读取数据，Hibernate的List速度很快，因为他是一次性把数据取完，这一点从观察任务管理器的java进程占用内存的变化也可以看得很清楚，内存几乎是10M的10M的增加。

6、JDBC读取数据的方式和Hibernate的List方式是一样的（这跟JDBC驱动有很大关系，不同的JDBC驱动，结果会很不一样），这 从观察java进程内存变化可以判断出来，由于JDBC不需要像Hibernate那样构造一堆Cat对象实例，所以占用JVM内存要比 Hibernate的List方式大概少一半左右。

7、Hibernate的Iterator方式并非一无是处，它适合于从大的结果集中选取少量的数据，即不需要占用很多内存，又可以迅速得到结果。另外Iterator适合于使用JCS缓冲。最终结论：