在我做过de很多项目de过程中,我一直有一个悬而未决de问题在困扰我,那就是持久层de开发.持久层de开发一般来说要么用CMP,要么用JDBC＋DAO. CMP就不用说了,它对我来说是一种失败de实践,而JDBC DAO也存在很多de困难,我很难做到把关系表记录完整de映射到持久对象de关系上来,这主要体现在多表de关系无法直接映射到对持久对象de映射上来,可能是一个表映射多个持久对象,有可能是多个表映射一个持久对象,更有可能de是表de某些字段映射到一个持久对象,但是另外一些字段映射到别de持久对象上.而且即使这些问题都处理好了,也不能直接按照对象de方式来对持久对象(PO)编程,因为存在1:N关系de持久对象de查询其实就是1 n次对数据库deSQL,我曾经有一次失败de持久层设计,结果是某个关联很多其它持久对象dePO一查询就是5n＋1次 sql,速度慢de不得了,最后不得不整个修改底层设计,最后等于是完全抛弃了对象设计,完全是按照表字段进行操作.
但是这样做非常难受,因为系统de设计是从需求设计,系统设计这样自顶而下de,结果都到了详细设计阶段了,被持久层映射问题限制,不得不自底向上修改设计方案,又回到了按照过程进行编程de老路上来,非常de糟糕.
我对这个问题思考了很久,最后终于意识到这其实是一个很经典de问题:对象和关系de映射问题.实际上自从OOP编程流行以后,就存在这个难题了,所以才有人提出关系数据库进行重新设计,改用对象数据库,但实际上关系数据库并没有被淘汰,于是就只能在上层de应用层找解决方案.这时候我明白了我需要de实际上是一种 ORM产品.
我最早想到deORM就是JDO,于是我下载了两个JDO产品,准备认真de学习一下,但是研究了一段时间之后,我发现我对JDO非常de失望,原因如下:
1、 JDO没有一个好de开源免费实现,好de产品都是商业产品,并且在国内没有销售和技术支持.这就造成了JDO只有学习之用,不能把它用在实际项目中,否则de话,您把软件卖给客户de时候,还要告诉他,您还要另外去买一个国外de软件产品,并且在国内没有技术支持,出了持久层de问题,我也解决不了,请您自己打国际长途去解决问题,您认为客户能答应吗？
2、JDO不是一个轻量级封装,它试图建立一个完整de持久层框架,但是还很不完善,造成了JDO 感觉比较笨重,很多操作方式令人觉得烦琐和古怪.这加重了程序员学习和编程de负担,而且封装de太多会造成一个严重de问题就是一旦出现报错信息,调试起来非常困难,您很难准确de定位错误究竟出在哪里,封装de越轻,问题越容易定位,越容易解决,封装de越重,问题越复杂,越找不到原因,CMP就是一个很好de例子,出了错误,调试起来非常困难和麻烦.
3、JDOde标准很不完善,存在重大缺陷.最主要de问题体现在PO不能脱离PM(相当于 HibernatedeSession)而存在,这是个非常严重de问题,会造成编程de时候进行大量VOde拷贝操作,烦琐极了；另外一个重大缺陷是静态de POJOdeEnhancer,不能运行期动态Enhance,无法进行增量编译和调试,编程和调试起来非常烦琐,每次都要手共运行一个工具对POJO进行 Enhance；此外还有一些缺陷,例如JDOQL不完善,映射关系de表达不够强大等等.
4、JDO产品de分裂.这个问题也比较严重,由于JDO1.0标准de缺陷,而JDO2.0标准还遥遥无期,而各个JDO厂商为了能够在竞争中脱颖而出,那么除了在易操作性和性能上de提高之外,想要吸引客户,就必须有自己de产品特色.那么1.0标准de缺陷正好给了他们发挥de舞台,每个厂商都会有自己独到de解决方案来解决标准de缺陷,然而这却造成了JDO 产品事实上de分裂.这种分裂严重到什么程度？我可以简单举个例子:您写好dePOJO,用一种JDOdeEnhancer进行Enhance过以后得到de PO,在另一个JDO产品上跑不起来.这很像当年Unixde分裂,结果就是二进制相关代码级de不兼容,而只能在C源相关代码级兼容.现在deJDO也有这样de趋势,就像App Serverde差别一样,一个在Weblogic上开发好deEJB,移植到Websphere,您一定需要重新进行配置.
我心目中deORM最好有如下de特点:
1、开源和免费deLicense,我可以在需要de时候研究源相关代码,改写源相关代码,进行功能de定制.
2、轻量级封装,避免引入过多复杂de问题,调试容易,也减轻程序员de负担.
3、具有可扩展性,API开放,当本身功能不够用de时候,可以自己遍码进行扩展.
4、开发者活跃,产品有稳定de发展保障.
抛弃了JDO以后,我根据上面de原则,先后排除了TopLink,CocoBase,Castor等,最后选择了Apache OJB和Hibernate.
OJBde排除很容易做出,一是因为它de文档太简单,太少；二是因为OJB计划下一个版本全面支持JDO,它deAPI会有重大变动,所以现阶段学习OJB是个错误,等它deAPI稳定了以后再学习不迟.
Hibernatede发现是很偶然de事情,只是在别人提到JDOde产品中,附带提了提而已,但当我开始研究Hibernate之后,我发现终于找到了我梦寐以求deORM了.
Hibernate 完全符合我上面提到de标准之外,也解决掉了JDOde所有缺陷,而且方式之优雅令人赞叹.Hibernatede文档也是非常非常有特色de地方,它不仅仅是 Hibernatede功能介绍那么简单,它实际上是一个持久层设计de最佳实践de经验总结,文档里面de例子,文档里面de总结全部都是最佳设计de结晶.我认真de把Hibernate读下来de感觉就是,不单单把Hibernate掌握住了,而且对持久层de设计de经验都长了一大块,以前可从来没有觉得持久层de设计还有那么多de学问,也由此感觉到Gavin绝对是一个大牛人.
当然选择Hibernate最最重用de原因是Hibernate是一个我能够完完全全驾驭de了de软件.Hibernatede源相关代码非常少,而且写de非常简洁,我总觉得挺奇怪de,这么少de源相关代码能够实现这么多de功能,是个奇迹. Hibernatede源相关代码树分de很清楚简单,源相关代码很易读,我一旦碰到文档中没有讲到de问题,或者文档中提到但是我搞不清楚de地方,我就去源相关代码中找,所有de问题都豁然开朗,而且让我对Hibernatede运行原理和细节搞de特别清楚,好像Hibernate就像自己写de相关代码一样,很清楚de知道,怎么写程序可以让Hibernate运行效率最高,最省内存,程序出了错误,很清楚de知道是什么地方de问题,怎么解决.所以用Hibernate让我特别放心,我能够驾驭它,而不像那些过于复杂de软件,本身框架就复杂de很,再加上不开源,出了问题也不知道怎么回事.
