为什么我们要研究Hibernate ？

这个问题可以推广一下，我们为什么要学习Java？你是为了谋生而学习，还是为了兴趣而学习。我曾经多次强调过，多从商业角度考虑问题，不要过于强调技术，也就是这个意思。没有人强迫你学习Hibernate，只不过这个论坛Hibernate的帖子一多，越来越多的研究Hibernate的人都被吸引到这里来的，就这么简单。

推而广之,可以进一步思考人是为什么活着的~~~

我学Java就是为了吃饭，我想还有其他的兄弟是同一个目的。
所以，我希望通过讨论，避免同志走弯路。
当然了，如果讨论后，我改变了主意，我就去研究Structs研究Hibernate然后，回答我能回答的问题。
呵呵。

存在即真理,思考一下存在的价值而不是存在的原因吧.
为什么所有的开发人员都要明白系统中的每一项技术呢?
为什么使用新技术的风险没有在项目开始前得到评估,在项目运行中得到控制呢?
用EJB,为什么?好处是什么?缺点是什么?成本和收益如何?
用Hibernate,重复上面的问题.
让技术成为实实在在的东西,驾驭技术,而不是被技术驾驭.

学习使用Hibernate并不会化太多时间的，我们的项目一共2个月时间，对于Hibernate基本的东西已经掌握。因此，如果项目需要，倒是可以学习。
至于学什么好，绝对和你的工作有关，你们的项目都是百万以上，统统j2ee，我们的项目都在十万上下，hibernate当然是我们的首选，整个项目下来，还不错，能有一些剩余。
至说sun的东西是最正宗，会有很多人不同意的，但这个问题又不会有标准答案，就争论了。
但是，开源的东西最大好处在我看来是他的源码可以看到，然后吸收入我们的设计当中，呵呵，这个无论你用ejb还是Hibernate，甚至.net都是可以借鉴的。
学习使用工具和标准可以提升我们的工作效率，却提升不了我们的设计。

我觉得你很逗，是否学习一个知识，没有人能够帮你回答这个问题，只有你自己能够回答，如果你觉得需要学习，那么就去学习，如果你觉得不需要，那么就不要浪费时间，难道你学习不学习，还要别人帮你做决定吗？那么生活中那么多比是否学习Hibernate更重用的决定，你又要找谁来帮助你做决定呢？父母吗？做人是否应该有点自己的主见？

每个学习Hibernate人都有他的原因和需要，或者因为工作需要，或者因为兴趣使然，或者打发无聊时间，或者人云亦云，你又是哪一种呢？我看你是自己不想学习Hibernate，觉得对自己的工作没有什么用处，也浪费宝贵的时间，但是你看到论坛那么多人都在学习Hibernate，又特别不甘心，生怕万一不学习，又错过了真正的好东西。真矛盾阿，所以一定要别人帮助你找出来一个让自己学习或者不学习的理由。

其实我觉得你的情况已经很清楚了，你不应该学习Hibernate，因为你用不到，就这么简单。拿我来说吧，虽然很多人都说，学习Java编程，一定要研究Jive和Petstore源代码，然而当我开始研究Jive和Petstore的源代码以后，我认为他们太理论化了，不实用，也许对别人有重大用处，但是对我则是毫无帮助，于是我就不去学习了。再拿GOF的设计模式来说吧，我从来不觉得GOF的设计模式对我有什么用处，我也根本不去学习GOF设计模式，但是我觉得J2EE设计模式对我特别有帮助，所以我会花时间去学习。虽然无数的人都说学习Java编程必学GOF设计模式，但是我认为对我来说没用，我就不去学习，就是到现在我也只能说过四五中GOF设计模式而已，但我不会因为别人的观点对我产生什么动摇。

可以研究一下嘛，作为一种技术的解决方案。
不一定深钻，但了解一些，有合适的项目时再深入。

J道J道，解决问题之道，真是精辟，真理。

本人非常同意Robbin的看法，呵呵，象Robbin这样道行的人确实不多见。

从业时间久了，专注于技术方案的设计与实现，以前见过不少自称是很牛的牛人，但大都或视野狭窄，专攻某一语言某一技术，任何系统都是程咬金的三斧头，系统虽说可以工作，但结果惨不忍睹；或华而不实，纸上谈兵，抱着UML等高深理论来套业务流程，结果往往更惨……

构建完美的系统是很多同人的目标与追求，什么样系统是完美的？首先要完美的符合商业应用的需要，这是评判系统好坏的硬道理。一味追求技术先进、体系优美、灵活扩展等如果偏离了应用的基本需求，是没有什么好处的。举例来说，本人在实时交易系统方面有过些经验，评判这样系统的标准大体就象下面概括的：交易事务的ACID必须保证，足够的安全性，在此基础上把业务逻辑正确的编码出来基本上就是一个不错的系统了，如果在体系结构、灵活扩展、集群负载均衡等面面俱到，就可以说是个完美的系统了。

技术人员在方案选择上往往有很多不同的看法和分歧，我认为这里面存在一个方向的问题，就是技术人员面对各种日新月异的技术时怎样取舍，是要技术视野博大还是技术专向精深的问题。本人一直坚持的一个观点就是，尽可能的对相关的领域知识要博大，然后把兴趣集中在某一方面，在这一方面做到精深。在我看来，现在大多数的技术人员，甚至是很多具有多年开发经验的老手都是专攻某项技术，甚至某一编程语言，知识面狭窄，而在项目方案选择上往往有失偏颇。

列在标准里面的东西，都是比较安全比较保险的东西，但是只有标准是远远不够的。

CMP对OO设计造成诸多障碍，所以我关注Hibernate。

Hibernate不是“标准”，所以大家对以后的日子很担心，需要吗？今天一切都很正常，这就够了。软件开发的技术变的这么快，鬼知道两年以后会怎么样？

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

这个论坛怎么回事，字数一多，就报错，害我一个帖子分三次贴，坛主应该关注一下了。