Home  >  Article  >  Database  >  为什么要学习Hibernate?_MySQL

为什么要学习Hibernate?_MySQL

WBOY
WBOYOriginal
2016-06-01 14:07:06754browse

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让我特别放心,我能够驾驭它,而不像那些过于复杂的软件,本身框架就复杂的很,再加上不开源,出了问题也不知道怎么回事。



Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn