为什么要学习Hibernate？

在我参与过的众多项目中，一直有一个悬而未决的问题困扰着我，那就是持久层的开发。面对CMP和JDBC＋DAO两种方案，我深感挑战。CMP的实践对我来说并不成功，而JDBC+DAO在映射关系表记录到持久对象时也存在诸多困难。尤其是当涉及到多表关系时，这种映射变得更加复杂。有时一个表需要映射到多个持久对象，有时多个表要映射到一个持久对象，甚至有些表的字段会映射到其他持久对象上。即便这些问题得到解决，我们仍不能像在编程时直接使用对象的方式来操作持久对象（PO）。对于那些存在1N关系的持久对象查询，实际上会生成多次对数据库的SQL查询。我曾经在一个项目中遇到过这样的问题，一个关联多个其他持久对象的PO查询会引发5n＋1次SQL查询，导致速度极其缓慢，最终不得不重新设计底层结构，放弃了原有的对象设计，重新按照表字段进行操作。

这种困境让我深感苦恼，因为系统的设计是从需求出发，自顶向下的设计流程。持久层的映射问题常常需要在详细设计阶段被迫自底向上修改设计方案，导致我们不得不回到按照过程进行编程的老路。我认真思考过这个问题，意识到这其实是一个关于对象和关系映射的经典问题。自从OOP编程流行以来，这个问题就一直存在。尽管有人提出对关系数据库进行重新设计，采用对象数据库，但关系数据库并未被淘汰。我们只能在应用层寻找解决方案。这时我意识到，我真正需要的是一种ORM产品。

我最早考虑的ORM是JDO，但我对其失望至极。原因如下：JDO缺乏良好的开源免费实现，好的产品都是商业性的，且在国内没有销售和技术支持。这使得JDO只能用于学习，无法在实际项目中使用。JDO不是一个轻量级的封装，它试图建立一个完整的持久层框架，但其实现并不完善，给人一种笨重的感觉。操作方式繁琐且古怪，增加了程序员的学习和编程负担。JDO的标准存在重大缺陷，例如PO不能脱离PM（相当于Hibernate的Session）而存在，这会导致大量的VO拷贝操作，增加编程的复杂性。由于JDO产品的分裂现象严重，不同的JDO产品之间存在二进制代码级的不兼容，这给我带来了极大的困扰。

在抛弃了JDO之后，我根据这些原则先后排除了TopLink、CocoBase、Castor等选项，最终选择了Apache OJB和Hibernate。关于OJB与Hibernate的选择与体验

对于OJB的排除，原因显而易见。其一，它的文档过于简略，内容匮乏，让人难以深入了解和掌握。其二，由于OJB计划下一个版本全面支持JDO，其API将有重大变动。现阶段学习OJB似乎有些为时过早，等待其API稳定后再行学习也不迟。

至于Hibernate的发现，纯属偶然。最初是在JDO产品时，Hibernate只是被附带提及。但当我开始深入研究Hibernate时，我意识到，这就是我一直在寻找的ORM工具。

Hibernate不仅满足了我对ORM的所有期待，更出色地解决了JDO存在的所有问题。其设计之优雅，令人赞叹。Hibernate的文档同样令人印象深刻，它不仅仅是介绍功能，更是持久层设计的最佳实践经验的结晶。阅读Hibernate的文档，让我不仅掌握了Hibernate本身，更积累了大量的持久层设计经验。我由衷地感叹，Gavin绝对是一个行业大牛。

我选择Hibernate的最重要原因，是它能够让我完全驾驭。尽管Hibernate的源代码非常简洁，数量惊人地少，但能够实现如此多的功能，简直是个奇迹。其源代码结构清晰，易于阅读。每当我在文档中找到问题或不解之处，我都会转向源代码寻找答案。每次深入研读后，我都会对Hibernate的运行原理和细节有更清晰的认识，仿佛Hibernate就像我自己编写的代码一样熟悉。我明白如何编写程序以最大化Hibernate的运行效率，最小化内存使用。一旦程序出错，我也能迅速定位问题并找到解决方案。使用Hibernate让我倍感放心，我能够完全掌控它，而不像某些复杂的软件，框架复杂且不开源，一出问题就束手无策。

Hibernate的稳定、简洁、开源以及强大的功能，使其在我心目中成为无可替代的ORM工具。它的优雅设计和卓越性能，使我在开发中如虎添翼，让我深感信赖和依赖。