J2EE基本之用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之间往返踌躇不决，甚至搞不清楚的话，措施都没有步伐写。