我为什么要学习Hibernate?
2008-01-05 08:15:28 来源:WEB开发网核心提示:在我做过的很多项目的过程中,我一直有一个悬而未决的问题在困扰我,我为什么要学习Hibernate?,那就是持久层的开发,持久层的开发一般来说要么用CMP,附带提了提而已,但当我开始研究Hibernate之后,要么用JDBC+DAO,
在我做过的很多项目的过程中,我一直有一个悬而未决的问题在困扰我,那就是持久层的开发。持久层的开发一般来说要么用CMP,要么用JDBC+DAO。
但是这样做非常难受,因为系统的设计是从需求设计,系统设计这样自顶而下的,结果都到了具体设计阶段了,被持久层映射问题限制,不得不自底向上修改设计方案,又回到了按照过程进行编程的老路上来,非常的糟糕。
我对这个问题思考了很久,最后终于意识到这其实是一个很经典的问题:对象和关系的映射问题。实际上自从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了。