<b>我学习Hibernate的来因</b>[Java编程]

在我做过的很多项目的历程中,我一向有一个悬而未决的问题在困扰我,那就是长期层的开辟.长期层的开辟普通来说要末用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让我分外安心,我可以驾御它,而不像那些过于复杂的软件,本身框架就复杂的很,再加上不开源,出了问题也不知道怎么回事.