为什么要学习Hibernate？
程序员文章站
2023-12-13 09:07:52
在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用cmp，要么用jdbc＋dao。 cmp就不用说了，它对我来说...
在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用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让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。
但是这样做非常难受，因为系统的设计是从需求设计，系统设计这样自顶而下的，结果都到了详细设计阶段了，被持久层映射问题限制，不得不自底向上修改设计方案，又回到了按照过程进行编程的老路上来，非常的糟糕。
我对这个问题思考了很久，最后终于意识到这其实是一个很经典的问题：对象和关系的映射问题。实际上自从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让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。