Hibernate的灵活与方便

    作者：Flyingis

    许多软件设计的思维都源于生活的方方面面，可能存在某些设计思想并非受平时生活所启迪，但它们面临的情况却如此相象。软件设计原本就是生活的一部分，软件设计的“灵活”与“方便”(或“简便”)即是世界万物的一个共同点。

    Hibernate作为流行的企业应用和关系数据库之间的持久化中间件，受到越来越多的关注。虽然使用Hibernate可以使得项目易于维护，帮助开发人员更好地处理复杂关系模型，提供了很强的方便性，但却失去了JDBC原有的灵活性。如何在“灵活”与“方便”之间取舍、平衡显得重要起来。

    不久前江南白衣的一篇文章ORM透明持久化方案面对的共同困境道出了现在ORM不尽如人意的地方，除了网上，还有书本的前言等对Hibernate的众多赞美之词外，现在讨论它呆板、配置繁琐的声音也逐渐多了起来，最热闹的就是前段时间Ruby on Rails引起J2EE阵营的骚动。个人对Java研究尚浅，对Hibernate有一些使用心得，下面所列出的不一定是Hibernate本身的缺陷，不足之处希望大家拍砖指出。

1.  提取表单中字典Value的不便。
    字典一般由ID和NAME两个字段组成，其ID号存储于数据库其他表中，当查询这些表信息时，Hibernate以List或Set形式返回的结果，没有办法将ID号显示为对应的NAME。在JDBC中，可以直接通过Map来存储字典，通过map.getValue()来返回字典的值。

2.  Hibernate内置映射类型复杂化
    在开发过程中，时常会查找Hibernate映射类型--Java类型--标准SQL类型之间的关系。繁杂之处体现在两方面，一是各种数据库的数据类型和标准SQL之间会有一定的出入，二是Hibernate映射类型虽然大部分和Java类型相同，但也存在比较晦涩的地方，例如character类型对应Java的char / java.lang.Character / java.lang.String，text对应着Java的java.lang.String。

3.  ID规定化生成
    Hibernate中内置标识符生成器给表单ID自动生成提供了方便，但却不能自定义各种ID形式。开发过程中，有时需要特定的ID号来区分各种字典，例如字典1的ID号为1A，2A……，字典2的ID号为1B，2B……，当这些ID号存储在表单中时，可以方便开发人员在数据库中查找各表单存储各类字典数据的情况，方便调试，但使用Hibernate生成器就失去了这种灵活性。

    Hibernate的不足网上已有很多讨论，以上只是个人增加的几点体会。即使这样，Hibernate仍是一款优秀的持久层插件，只是“灵活”的背后隐藏着“复杂”，“方便”的背后隐藏着“不便”，如何取舍与平衡，还是看实际需要吧。