Hibernate FAQ

类别:Java 点击:0 评论:0 推荐:
下面的文章只是让大家认识一下Hibernate的优势和未来,有没有必要学习要看你的实际需求,不过还是建议你在有时间的情况下研究一下,如果能用到项目当中那更好。如果你的基础还没有牢固,请你三思而行。

Hibernate FAQ 初学者必读!

1、Hibernate是什么?

Hibernate是一个优秀的开发源代码的Java对象持久层轻量级封装框架,它既可以用来在Java应用程序中取代大部分JDBC代码,也可以整合到J2EE系统中作为持久层框架。

2、Hibernate的官方网站是什么?

http://www.hibernate.org/

3、Hibernate是谁开发的?

Gavin King

4、Hibernate的下载地址?

http://sourceforge.net/projects/hibernate/

5、Hibernate的文档在哪里?

http://www.hibernate.org/5.html

6、Hibernate的当前稳定版本是哪个版本

Hibernate2.0.3

7、Hibernate有专门的论坛吗?

官方论坛(英文) http://forum.hibernate.org/

国内论坛(中文) http://forum.hibernate.org.cn/

8、Hibernate有例程吗?

http://www.hibernate.org/30.html


-----------------------------------------------------------

Hibernate入门容易,掌握精通我也不敢自夸。我第一遍看Hibernate文档的时候也觉得很吃力,但不是因为Hibernate难掌握而感到吃力,是因为Hibernate文档处处都是持久层设计的经验和最佳实践。Hibernate文档准确的来说,绝大部分内容都在讲对象的持久层设计,而不是简单的Hibernate使用,使用问题查Java doc就够了。所以学习Hibernate,主要是在学习持久层的设计模式,如果你把Hibernate文档都看完了,还整天只会提那些 Hibernate的配置问题,Hibernate的类调用问题,我觉得这样的人还没有真正的入门,算是白学了。

我对Hibernate 的那些配置也不是特别纯熟,每次写hbm,都要对照文档一点点的检查;类调用参数也不太记得,写代码也要Java doc随时备查。但是我在学习Hibernate的时候即集中所有精力来理解Hibernate的运行原理,集中精力来掌握持久层设计应该把握的原则和技巧,这些才对我是最重用的东西。毫不夸张的说,学习完Hibernate,我对JDBC的编程也提高了一大截,更不要说对于J2EE架构的持久层的框架设计,基本上是了然于胸了,即使将来换了API,不用Hibernate的,改用JDO,Castor什么的,这些经验一样照用。

学习Hibernate主要不是在学习Hibernat怎么配置,用工具怎么生成hbm文件,如果你把重点放在这里,基本上等于白学了Hibernate。Hibernate的精华在于无与伦比的灵巧的对象持久层设计,这些持久层设计经验不会因为你不用Hibernate而丧失掉,我自己学习Hibernate,已经明显感觉到对持久层设计能力已经长了很多经验值了,这些经验甚至不光可以用在Java上,用在.net上也是一样。所以Hibernate配置的学习,我只是简单看看,用的时候知道到那里去查就行了,一堆复杂的生成工具我根本就看都不去看,这样算下来,掌握Hibernate的配置,可以用Hibernate来替代JDBC写程序,不过花上3天时间就足够了。我想3天时间对你来说不算很奢侈的学习代价吧。

为什么我这么强调学习Hibernate的对象持久层设计理念呢?那就看你的理想是想一辈子做一个程序员呢?还是想向更高的方向发展呢?从纯做技术的角度来说,职业发展的最高点是“系统架构师”,Bill Gates不是还叫做微软的首席系统架构师吗?System Architect职位需要的是你的学习和领悟能力,如果你不能把学习Hibernate得到的设计经验运用到其它地方,那么你是失败的,也没有资格做 System Architect。

不管JDO也好,Hibernate也好,TopLink也好,CocoBase也好,还是 Castor,还是什么Torque,OJB,软件的使用和配置方法可以各异,但本质上都是ORM,都是对JDBC的对象持久层封装,所以万变不离其宗,如果你完整的学习和掌握Hibernate花了1个月的时间,那么你再学习OJB的时间不应该超过1个星期,因为你已经把对象持久层设计都了然于胸了,你需要的只是熟悉一下OJB的API和配置罢了,至于怎么运用OJB进行持久层的开发你早就已经熟悉了。

所以当你掌握了两种以上的ORM,你应该能够不拘于使用的ORM软件的限制,设计出适合于你的项目的持久层来,这才是System Architect的水准。用金庸小说来打个比方来说吧,张无忌学太极剑,只记剑意,不记剑招,这才是真正的高手,而低手就只会去学习剑招,而不去领会剑招背后蕴含的剑意,所以一辈子都是低手,永远不能真正学会太极剑。所以周颠看到张三丰第二次演示太极剑,招式完全不同就以为是另一套东西,其实本质上都一样。学习Hibernate也不要舍本逐末的去学各种五花八门的工具,重点掌握它的对象持久层设计理念。


--------------------------------------------------------------

我来谈谈我为什么学习Hibernate,希望对大家能有点启发。

在我做过的很多项目的过程中,我一直有一个悬而未决的问题在困扰我,那就是持久层的开发。持久层的开发一般来说要么用CMP,要么用JDBC+DAO。 CMP就不用说了,它对我来说是一种失败的实践,而JDBC+DAO也存在很多的困难,我很难做到把关系表记录完整的映射到持久对象的关系上来,这主要体现在多表的关系无法直接映射到对持久对象的映射上来,可能是一个表映射多个持久对象,有可能是多个表映射一个持久对象,更有可能的是表的某些字段映射到一个持久对象,但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了,也不能直接按照对象的方式来对持久对象(PO)编程,因为存在1:N关系的持久对象的查询其实就是1+n次对数据库的SQL,我曾经有一次失败的持久层设计,结果是某个关联很多其它持久对象的PO一查询就是5n+1次 sql,速度慢的不得了,最后不得不整个修改底层设计,最后等于是完全抛弃了对象设计,完全是按照表字段进行操作。

但是这样做非常难受,因为系统的设计是从需求设计,系统设计这样自顶而下的,结果都到了详细设计阶段了,被持久层映射问题限制,不得不自底向上修改设计方案,又回到了按照过程进行编程的老路上来,非常的糟糕。

我对这个问题思考了很久,最后终于意识到这其实是一个很经典的问题:对象和关系的映射问题。实际上自从OOP编程流行以后,就存在这个难题了,所以才有人提出关系数据库进行重新设计,改用对象数据库,但实际上关系数据库并没有被淘汰,于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种 ORM产品。

我最早想到的ORM就是JDO,于是我下载了两个JDO产品,准备认真的学习一下,但是研究了一段时间之后,我发现我对JDO非常的失望,原因如下:

1、 JDO没有一个好的开源免费实现,好的产品都是商业产品,并且在国内没有销售和技术支持。这就造成了JDO只有学习之用,不能把它用在实际项目中,否则的话,你把软件卖给客户的时候,还要告诉他,你还要另外去买一个国外的软件产品,并且在国内没有技术支持,出了持久层的问题,我们也解决不了,请你自己打国际长途去解决问题,你认为客户能答应吗?

2、JDO不是一个轻量级封装,它试图建立一个完整的持久层框架,但是还很不完善,造成了JDO 感觉比较笨重,很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担,而且封装的太多会造成一个严重的问题就是一旦出现报错信息,调试起来非常困难,你很难准确的定位错误究竟出在哪里,封装的越轻,问题越容易定位,越容易解决,封装的越重,问题越复杂,越找不到原因,CMP就是一个很好的例子,出了错误,调试起来非常困难和麻烦。

3、JDO的标准很不完善,存在重大缺陷。最主要的问题体现在PO不能脱离PM(相当于 Hibernate的Session)而存在,这是个非常严重的问题,会造成编程的时候进行大量VO的拷贝操作,烦琐极了;另外一个重大缺陷是静态的 POJO的Enhancer,不能运行期动态Enhance,无法进行增量编译和调试,编程和调试起来非常烦琐,每次都要手共运行一个工具对POJO进行 Enhance;此外还有一些缺陷,例如JDOQL不完善,映射关系的表达不够强大等等。

4、JDO产品的分裂。这个问题也比较严重,由于JDO1.0标准的缺陷,而JDO2.0标准还遥遥无期,而各个JDO厂商为了能够在竞争中脱颖而出,那么除了在易操作性和性能上的提高之外,想要吸引客户,就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台,每个厂商都会有自己独到的解决方案来解决标准的缺陷,然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度?我可以简单举个例子:你写好的POJO,用一种JDO的Enhancer进行Enhance过以后得到的 PO,在另一个JDO产品上跑不起来。这很像当年Unix的分裂,结果就是二进制代码级的不兼容,而只能在C源代码级兼容。现在的JDO也有这样的趋势,就像App Server的差别一样,一个在Weblogic上开发好的EJB,移植到Websphere,你一定需要重新进行配置。

我心目中的ORM最好有如下的特点:

1、开源和免费的License,我可以在需要的时候研究源代码,改写源代码,进行功能的定制。

2、轻量级封装,避免引入过多复杂的问题,调试容易,也减轻程序员的负担。

3、具有可扩展性,API开放,当本身功能不够用的时候,可以自己遍码进行扩展。

4、开发者活跃,产品有稳定的发展保障。

抛弃了JDO以后,我根据上面的原则,先后排除了TopLink,CocoBase,Castor等,最后选择了Apache OJB和Hibernate。

OJB的排除很容易做出,一是因为它的文档太简单,太少;二是因为OJB计划下一个版本全面支持JDO,它的API会有重大变动,所以现阶段学习OJB是个错误,等它的API稳定了以后再学习不迟。

Hibernate的发现是很偶然的事情,只是在别人提到JDO的产品中,附带提了提而已,但当我开始研究Hibernate之后,我发现终于找到了我梦寐以求的ORM了。

Hibernate 完全符合我上面提到的标准之外,也解决掉了JDO的所有缺陷,而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方,它不仅仅是 Hibernate的功能介绍那么简单,它实际上是一个持久层设计的最佳实践的经验总结,文档里面的例子,文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是,不单单把Hibernate掌握住了,而且对持久层的设计的经验都长了一大块,以前可从来没有觉得持久层的设计还有那么多的学问,也由此感觉到Gavin绝对是一个大牛人。

当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少,而且写的非常简洁,我总觉得挺奇怪的,这么少的源代码能够实现这么多的功能,是个奇迹。 Hibernate的源代码树分的很清楚简单,源代码很易读,我一旦碰到文档中没有讲到的问题,或者文档中提到但是我搞不清楚的地方,我就去源代码中找,所有的问题都豁然开朗,而且让我对Hibernate的运行原理和细节搞的特别清楚,好像Hibernate就像自己写的代码一样,很清楚的知道,怎么写程序可以让Hibernate运行效率最高,最省内存,程序出了错误,很清楚的知道是什么地方的问题,怎么解决。所以用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个架构没有区别。

本文地址:http://com.8s8s.com/it/it10064.htm