J2EE底子之用Hibernate企业框架的所长[Java编程]

1、Hibernate是JDBC的轻量级的对象封装,它是一个独立的对象长期层框架,和App Server,和EJB没有什么必定的接洽.Hibernate可以用在任何JDBC可以利用的场所,比方Java利用程序的数据库拜候代码,DAO接口的实现类,乃至可以是BMP里面的拜候数据库的代码.从这个意义上来说,Hibernate和EB不是一个范围的东西,也不存在非此即彼的关系.

2、Hibernate是一个和JDBC密切关联的框架,所以Hibernate的兼容性和JDBC驱动,和数据库都有一定的关系,但是和利用它的Java程序,和App Server没有任何干系,也不存在兼容性问题.

3、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个架构没有辨别.

4、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之间往复犹豫不决,乃至搞不清楚的话,程序都没有办法写.