表格只是用来起到一个登记保存作用的，而且都是独立的一张表，表与表之间没有复杂的关系，并且只需要提供基本的添加、删除、编辑、保存的功能和一些基简单条件查询的功能就能满足它们的功能需求。

     ＡＤＯ．ＮＥＴ数据访问技术中操作数据库的核心对象——ＤａｔａＳｅｔ是一个复杂的数据结构，允许以驻留内存的形式来表示几乎所有关系模型。

    但是，它并没有避开“阻抗不匹配”的问题，因为它需要我们编写代码来把关系数据库中的结构映射到它的结构，把关系数据库中的数据传到对应的位置。

    也需要我们编写ｓｑｌ语句传给相关的数据操作类来告诉它要在数据库进行什么操作和怎样进行操作。

    使用这种方式编程，因为每个表的字段不同，表名 第１血 国防科学技术人学研究生院学位沦文不问，所以我们不得不为每一个表对应的编写一个数据访问的类——尽管这些类的代码很相似，实现的功能也一样。

    我们清楚的意识到一旦数据库里面的表结构发生了变化，就不得不修改对应的代码并且重新编译，而且在修改过程中又可能会带来Ｂｕｇ，这上面将会耗费大量的人力，物力和时间。

    因此从系统研发开始前两个月，就积极和用户配合，深入它们各个部门了解需求，希望在需求阶段能确定好大多数表的结构以避免以后的修改维护代价。

     可是，很快发现这几乎是不可能实现的。

    大多数用户自己都并不太清楚他们到底需要表旱面有哪些内容，而且由于在系统中流转的电子表是跟实际的表在结构要求上有一定差异的，这些用户根本不清楚。

    而由于知识背景的不同。

    我们也难以深入理解他们的实际需要。

    所以在项目初期我们和用户共同制定的需求说明书中定义的表的格式和内容在项目后期基本都变动了。

    并且往往是每次我们修改以后再给用户使用时，他们才能确定下一步的需求，所以每个表都变动了好几次。

    这就势必造成了工作量的增加，项目不能按时完成，一再延期。

    本人试图在技术上寻求解决这个问题的有效方法。

     §１．２国内外研究现状１．国外研究现状 早在１９９８年，Ｓｃｏｔｔ ｗ Ａｍｂｌｅｒ就写出了关于ＯＲＭ Ｐｅｒｓｉｓｔｅｎｃｅ Ｌａｙｅｒ的详细设计论文川，在文中，他提出了Ｃｌａｓｓ Ｔｙｐｅ Ａｒｃｈｉｔｅｃｔｕｒｅ的结构设计思想，并基于该思想设计了一个持久层框架。

    后来Ａｒｔｅｍ Ｒｕｄｏｙ根据这个框架开发了一个开源的ＯＲＭ实现一ＰＬ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｌａｙｅｒ）开源项目。

    【２Ｉ该组件的出现，验证了Ｓｃｏｔｔ的持久层设计的可行性和先进性，从而使得与ＯＲＭ组件相关的研究与实现迅速的成为了热点。

     文献〔３〕中描述了ＯＲＭ组件——ｏｂｊｅｃｔＤｒｉｖｅｒ，该组件允许在关系数据库上增加一个对象视图，提供了Ｊａｖａ和Ｃ＋＋的绑定，并实现了部分对象查询（ＯＱＬ）语句向ＳＱＬ语句的解释转换；文献【４】描述了０ＲＭ组件——ｈｉｂｅｒｎａｔｅ，他实现了对象查询（ＯＱＬ）语句向ｓＱＬ语句的解释转换，提供了真正意义上的对象化查询操作，在很大程度上做到了数据库的无关性从而起名为ｈｉｂｅｒｎａｔｅ，意思是冬Ｈ民的数据库。

     但是，上述的所有关于对象——关系映射的研究都没能提供关于这种映射是否完备的证明。

    由于关系模型和对象模型之间的差距，实现完全意义上的对象——关系映射是非常困难的，以至在Ｓｃｏｔｔ ｗ。

    Ａｍｂｌｅｒ在论文中ｆ１１提出了警告：“构建一个持久层惊人的困难”。

     最后，Ｍａｒｔｉｎ Ｆｏｗｌｅｒ在文献【５〕中，把对象关系映射当作了一个设计模式加以叙述和论证，并对其他相关子模式也进行了详细的阐述。

    该书可以算是对近年来的ＯＲＭ的研究成果和技术作了一个总结。

    在书中他提到：“我认为模式是一种半生不熟品，为了用好它，必须在自己的项目中把剩下的那一半火候补上”。

    ２．国内研究现状 塑堕里丛：里塑童苤！！！塑竺茎堑竺垄塑生塑堕垦：垄塞蔓！！ｊ！：至壅壹堕垫翌堕 箱２虹 国防科学技术人学研究生院学位论文嵌ＳＯＬ、紧福合和健壮持久层技术等３种常用持久化方法的研究，说明了他们各自特点，并比较了３种方法的优缺点。

    他还建议开发者根据自己的情况来考虑是使用较简单的实现方法