Grove在OR Mapping中应用.docVIP

Grove在OR Mapping中应用 　　[摘要] 本文论述了O/R Mapping的运行机制和在.NET应用程序开发中应用Grove工具如何实现O/R Mapping映射框架。 　　[关键词] Grove O/R Mapping SQL 　　 　　一、引言 　　面向对象思想在当今应用程序开发中占有主导地位，而大部分的企业级应用都是建立在数据库基础上，因此数据库的对象化为构建企业级应用提供极为便利的条件。目前大部分面向对象的系统采用的做法一般为: 　　在两层架构中的客户端硬编码SQL语句，将获取的数据还原成类的实例；将数据库的访问独立出来，连同业务逻辑作为中间层。仍然通过编码的方式进行对象与关系数据库之间的O/R转换。 　　这样在开发过程中，常常有一些业务逻辑需要直接写SQL语句实现，其结果是:遍地布满SQL语句。这些高藕合的SQL语句给系统的改造和升级带来很多无法预计的障碍。当数据库结构或是类抽象中的任何一方发生变化，这样的结构不可避免地导致系统的大幅修改。同时，编码中的很大一部分将用于实现关系数据库与类实例的转换。 　　所以，为了提高项目的灵活性，特别是快速开发，我们选择在数据访问层与数据存储层中间加入ORM层。这样当数据库模型改变时，不再需要理会逻辑代码和SQL语句中涉及到该模型的所有改动，只需要将该模型映射的对象稍作改动，甚至不做改动就可以满足要求。 　　为此我们在设计应用程序框架中提出一个模型：在业务逻辑层和关系数据库之间增加一个Persistence Layer，负责实现对象和关系数据库之间的映射。利用这个O/R Mapping框架的机制，对象与关系数据库之间的转换就可以透明地进行，而不用去关心数据库连接、并发性、事务等等问题。也就是说，业务逻辑层直接获取或存贮的就是清晰的对象，中间的转换过程就交给Mapping框架处理了（如图1所示）。 　　二、O/R Mapping机制 　　根据抽象对象与关系数据库的特性，O/R Mapping在以下几个方面实现: 　　1.类属性映射到数据表列 　　类属性和表列并非一一对应。一个类属性可对应0或多个实体表的字段。例如：作为保存中间结果，或是标明类在某一运行时刻状态就不需要保存在数据库中，作为对象在数据库中的惟一标识，同时为了避免因???务规则变化而引起的数据库字段和键值的频繁变化，通常采用无业务意义的字段OID作为各个实体表的主键。OID也作为类与数据库映射时的对象的惟一标识。 　　2.类映射到数据表 　　不同层次的类映射到数据表时，应该根据实际的系统设计结果，从以下几个角度权衡，采用适当的映射策略：实现难易度、数据访问难易度、对象与数据库耦合度、数据访问速度、数据库字段冗余度以及多态性支持程度。 　　可以采用的映射策略主要分为以下三种： 　　(1)一个类层次对应一个数据表 　　这里所说的一个类层次，指的是父类及其所有子类。将父类和子类中有持久性需求的属性设置为同一数据表的字段。此方法实现起来简单，并且较好地支持多态。因为不同的子类可以用一个标志位加以区分。子类实例的转换比较容易实现。但是，类与数据库之间的耦合程度高。由于子类所特有的属性被所有类层次中的对象所共有，数据库中冗余字段较多。 　　(2)一个实体类对应一个数据表 　　各个子类所特有的属性，联合从父类中继承的公共属性，构成表的结构。父类不映射为数据库中的实体表，它只作为子类公共属性的载体。简单图如图2所示。 　　这种映射模型使得类属性值的保存和对象还原实现方便。缺点同样是类结构与数据库的耦合程度高，特别父类属性变列时，所有从此继承下来的子类都需要进行变更。 　　此外，对多态性的支持较差。子类的角色转换需要在子类对应的数据表之间准确地传递适当的属性值，同时，需要赋予新的OID。例如，由ConcreteClass1中的一个实例转换成ConcreteClass2的一个实例，即通常情况下的角色转换。由于父类没有对应的实体，不得不将该实例在ConcreteClassTable1中的公共属性值抽取出来，通过Parent类构建ConcreteClass2的实例，给 SpecAttributeE和SpecAttributeF赋值。在持久性保存时，在 ConcreteClassTable2中生成一个新的OID。这种情况下，就不如第一种映射模型，用同一个OID，在同一张表内就可以实现不同子类之间的转换。 　　(3)一个类对应一个数据表 　　无论是父类还是子类，只要类中的属性有持久性保存的需要，就将类映射到数据表。子类的表以父类类表的OID为外键。在关系数据库中最大程度地实现了类的多态性。与前两者比较，对象与数据库的耦合程度是最低的，某一个类属性的变更引起的表结构变动最少。 　　这种方法