[转贴] Hibernate的优点,为什么用Hibernate

鉴客 发布于 2010/10/20 12:11
阅读 1K+
收藏 7

一、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之间来回犹豫不决,甚至搞不清楚的话,程序都没有办法写。

加载中
0
joliny
joliny

我换来换去最终还是换到了jdbc。呵呵!!

0
小杨阿哥哥
小杨阿哥哥

JDBC 毕竟SQL是根本。

JFinal
JFinal
完全赞同,回归问题的本质
0
shijacky
shijacky

一般都是 jdbc -> 框架 -> jdbc

0
mallon
mallon

喜欢单独使用Hibernate

0
我有我格
我有我格

我还是比较喜欢使用Hibernate:

原因如下:

1.提高开发效率,我觉得这个在实际的开发中非常重要.

2.使用Hibernate Search可以快速开发基于Lucene的全文检索.

3.使用hibernate-memcached实现分布式二级缓存功能.

4.使用Hibernate的审计功能实现审计,这在许多项目中都会碰到.

0
JFinal
JFinal
用过ruby on rails 的 ActiveRecord后就知道 Hibernate开发是多么地低效了
0
newtypelv_9
newtypelv_9
hibernate提高了开发者的效率,在项目中大多数的情况下还是可以用的,但有些对处理数据量较大的情况下还是使用jdbc比较适合。
返回顶部
顶部