从关系数据库中检索对象并将其保存到关系数据库

摘要

允许对象关系映射中的一致导航(对数据库和存储器环境)的系统和方法。这一般经由对持久对象(例如，实体集、实体引用...)的集合的限制来确保对象图的保真度。而且，跟踪组件可在改变发生时检测改变，并且仅经改变的对象的副本被创建以便优化操作。

说明书

背景

随着对于众多公司而言软件的战略价值的增加，软件厂商不断找出自动化软 件生产并改进质量、减少成本和推向市场的时间的新技术。这些技术包括组件技术、 可视编程、模式和框架。随着软件系统的复杂性在范围和规模上的增加，各个公司 寻求管理并解决这种复杂性的技术，这些复杂性包括重复出现的体系结构问题，诸 如物理分发、容错、复制、安全性、并发性和负载平衡。另外，因特网的发展在使 得某些通信交换大大简化的同时，加剧了这些体系结构上的挑战。

具体地，一个常见的软件体系结构表示是类图。类图表示描述系统中的符号 的静态结构的图形表示，并示出声明性(静态)模型元素，诸如类、类型及其内容 和关系的集合。类被安排成共享共同的结构和行为的分层结构，并与其他类相关联。 类图使用诸如类、封装和对象等设计元素来对类结构和内容建模，并且还显示诸如 包含、继承、关联等关系。在面向对象编程术语中，类是定义面向对象程序中的一 组对象的结构和行为的元素。在面向对象的应用程序中，类具有属性(成员变量)、 操作(成员函数)以及与其他类的关系。

而且，代码生成在对象关系映射(ORM)上下文中变得流行。关系数据存储 系统(例如，DB2、SQL Server、MySQL等)被共同用来存储关系数据并管理相 关联的关系。期望用源级语言开发的软件能访问并操纵存储在关系数据存储系统中 的关系数据。当应用程序软件正管理关系数据时，也期望维护数据中固有的关系。 另外，对关系数据的任何改变或修改也应被存回关系数据存储系统。

一般而言，面向对象的语言并不向软件开发员提供管理关系数据并确保关系 一致性的工具。例如，当使用面向对象的源代码来映射用于诸如顾客定单关系等一 对多关系的数据时，通常无需这样的特征来映射。从而，当用关系数据来填充对象 时，一般是程序员来负责确保对象与关系数据一致。类似地，当诸如定单等对象被 移除时，程序员负责确保所有的相关关系均被更新。如果删除了一个定单，则这样 的定单必须从用于相关的顾客的定单列表中移除。

另外，一旦从数据库检索数据并将其转换成对象之后，然后数据访问层可能 丢失其跟踪改变的能力，且可考虑两个分开的环境，即：数据库和存储器。在数据 库环境中，采用行和列，且值提供对所需对象的访问。相反，在存储器环境中，一 般可采用指针，且一般对对象标识不执行任何值匹配或比较。

在这样的环境中在数据库与存储器之间可能发生不一致性，例如在调试操作 期间或当对象被修改、删除或插入时。然后可能触发错误，拒绝将数据保存到数据 库中。而且，所发出的后续命令的顺序还可增加对象关系映射中涉及的复杂性。

而且，在对象关系映射系统的操作中存在低效。例如，当程序员代码导致存 储器中对象的改变时，对象一开始被带到存储器中并在其中维护一副本。这样的副 本可被保存以用于稍后需要保存操作时进行的比较。为所有加载的对象创建这样的 副本可消耗与计算基础架构相关联的资源。

概述

以下提出本发明的简化概述以提供对其某些方面的基本理解。该概述不是本 发明的详尽概观。它不旨在标识本发明的关键/重要的元素，也不旨在描绘本发明 的范围。其唯一目的是以简化形式呈现本发明的某些概念，作为将在稍后呈现的更 详细描述的序言。

本发明提供了允许以一致的方式(对数据库和存储器环境)导航且一般经由 对持久对象(实体集、实体引用)的集合的限制来确保对象图的保真度的对象关系 映射的系统和方法。从而，提供了一种命令性程序设计模型，其中用户为实体集采 用特定的集合类，诸如通过提供双向一致的指针，一般可确保存储器侧中的对象图 的保真度。例如，可提供雇员部门类(实体集)，使得当用户采用这样的特殊对象 且在添加了雇员时，雇员部门属性可指回这样的部门，以防止不一致性。因此，在 对象的生命周期期间，可在创建(Create)、读(Read)、更新(Update)和删除 (Delete)(CRUD)操作期间维护这一构建的关系。而且，由于存储器中的对象 存在于堆中，因此可提供用于感兴趣的对象的表以提供关于基础架构的根的知识。 这样的感兴趣对象的表可减轻对递归走查(walk)相应图的要求。实体集和实体引 用的指针是双向一致的，以便正确地维护对象关系之间的保真度。对存储器中的对 象的修改然后可被推回到数据库侧。

根据本发明的方法，对象首先被加载到存储器中，继之以在其上执行修改。 这样的修改可包括更新、插入或删除。例如，其中有两个雇员工作的部门可被加载 到存储器内。随后，雇员可被删除，或另一雇员可被添加到这样的部门，改变被存 回数据库中。当雇员要被删除时，这样的删除可被显式指示。

在一相关方面中，可通过实施两个约束，即维护对象身份以及确保作为检索 到的实体的一部分的实体集合的保真度来提供对象保真度。一般，在数据库侧，可 经由主键维护对象身份，其中如果两个项目指向同一存储器位置并维持引用等同 性，则它们可被认为是相同的。当检索同一行两次(例如，经由查询的不同部分) 时，它们由同一对象(例如，身份图)表示。维护对象身份可通过维护对应于实体 的主键(或唯一键)值并一般确保对给定标识(id)值不存在一个以上的对象来实 现。

同样地，为了确保作为检索到的实体的一部分的实体集合的保真度，对给定 的实体，实际上一般应可访问所有相关实体(例如，实体引用和实体集的导航)。 而且，本发明可提供对存储器的惰性加载和/或急性加载。例如，在其中有两个雇 员工作的部门的情况中，该部门可在不加载两个雇员的情况下加载(懒惰加载)， 或也将可通过该部门触及的其他内容加载到存储器中(急性加载)。

根据本发明的另一方面，一跟踪组件可在改变发生时检测改变，且可仅创建 经改变的对象的副本。这可提供优化检测对象改变并维护原始值所需的空间和时间 的优化算法。另外，相应的比较工作可被显著减少。

在一相关方面中，所感兴趣的对象的表中的每个对象均有状态。当添加一对 象时，跟踪组件可观察所有相关的项，且当一对象被标记为要删除时，所有相关的 子对象将均被自动删除。而且，当对象被改变时可提供通知，且可保存未经改变的 状态的副本，以便稍后与经修改的版本进行比较。因此，系统资源可被高效使用。 而且，可向程序员给出使用带有命令性框架的代码生成工具的选项，且他们可获得 这样的优化好处，或者按需编写类并丧失这样的优化。

为了实现前述和相关目的，此处结合以下描述和附图描述了本发明的某些说 明性方面。然而，这些方面仅指示可采用本发明的原理的众多方式中的少数几种， 且本发明旨在包括所有这样的方面及其等效方式。本发明的其他优点和新颖的特征 当结合附图考虑本发明的以下详细描述时将是显而易见的。

附图简述

图1示出了对于对象关系映射系统示出数据库侧与存储器侧之间的关系的示 意图。

图2示出了经由实体集和实体引用的一致性导航的实现，实体集和实体引用 是维护底层关系的保真度的组件，它们从主键外键关系中形成。

图3示出了用于三个类模型的零到多雇员关系以及与一雇员相关的零个或一 个职位的示意图。

图4示出了雇员的实体集与单个部门的实体引用之间的双向导航。

图5示出了职位的实体集与雇员的实体引用之间的另一双向导航。

图6示出了示出数据库侧与存储器侧之间的关系的示意图，其中实体集和实 体引用提供对象保真度。

图7示出了根据本发明的一方面修改数据库的示例性方法。

图8示出了根据本发明的一方面删除对象的示例性方法。

图9示出了根据本发明的一方面更新对象的示例性方法。

图10示出了根据本发明的一方面插入对象的示例性方法。

图11示出了根据本发明的一方面用于最优改变跟踪的流程图。

图12是示出顾客定单关系示例的框图。

图13示出了用于经改变的对象的跟踪优化的流程图。

图14示出了其中可实现本发明的各方面的合适的计算环境的简要、概括描述。

图15示出了可采用经由本发明的实体集实体引用安排的对象保真度的客户机 -服务器系统。

详细描述

现在参考附图描述本发明，在全部附图中，同样的参考标号指的是相同或相 应的元素。在以下描述中，为说明起见，描述各种具体细节以便提供对本发明的彻 底理解。然而，显然，本发明可无需这些具体细节来实现。在其他情况中，用框图 形式示出了公知的结构和设备以便于描述本发明。

如本申请中所使用的，术语“组件”、“系统”等指的是计算机相关的实体， 它们或者是硬件、硬件和软件的组合、软件或者是执行中的软件。例如，组件可以 是，但不限于，运行在处理器上的进程、处理器、对象、可执行代码、执行的线程、 程序和/或计算机。作为说明，运行在服务器上的应用程序和服务器本身都可以是 组件。一个或多个组件可以驻留在进程和/或执行中的线程内，且组件可以位于一 台计算机上和/或分布在两台或多台计算机之间。

图1示出了在对象关系映射系统100中存储器侧102与数据库侧104之间的 关系的示意图。例如，在数据库侧104上，顾客和定单列表可被表示为表，其中现 有关系可以是主键(PK)-外键(FK)的形式，指针从FK指向PK(外键可以是 用来建立并实施源表与目标表数据之间的链接的列或列组合)。

另一方面，当顾客和定单列表被移动到存储器时，顾客与定单之间的典型自 然形式的表达是维护定单的集合。从而，代替具有指向顾客的一定单，这样的顾客 具有定单的集合。而且，指针是从PK指向FK的，且当与数据库侧比较时方向不 同。

在存储器侧102上，对象可存在于堆上，且本发明的一致导航特征110允许 对存储器侧102执行的更新被反映并被推回关系数据库侧104，尽管事实上关系侧 104中的导航链接一般是从外键到主键，而在存储器侧102是相反方向。这样允许 以一致的方式(对数据库和存储器环境)导航，且一般经由对持久对象(实体集、 实体引用)的集合的限制来确保对象图的保真度。从而，提供了命令性的程序设计 模型，其中用户为实体集采用特定的集合类，诸如通过提供双向一致的指针一般可 确保存储器侧中的对象图的保真度。

图2示出了指定的实体集202和实体引用204的生成，实体集和实体引用是 维护底层关系的保真度的组件。这样的实体集和实体引用便于在存储器侧中双向导 航，且提供存储器侧与数据库侧之间的一致性。可通过采用实体集202和实体引用 204来生成对应于表的类。

对象关系映射

一般，对象关系映射(ORM)允许类被映射到表或由一个或多个表组成的视 图。该视图可在数据库中定义，或通过诸如映射文件或源代码属性等映射伪影 (artifact)来定义。在作为对象引用或引用集合建模的类之间可能存在关系。图3 示出了具有如将在以下详细描述的彼此相关的三个类Division(部门)310、 Employee(雇员)320和Position(职位)330的示例性模型。因此，在部门中存 在零到多个雇员(1∶n关系的示例)，以及与Employee相关的零到一个职位(1∶ 1关系的示例)。

通过实现实体引用和实体集，可创建部门与雇员之间的双向关系。在对象世 界中，实体集可收集指向相应部门的所有雇员。例如：

create table DivisionTable  (

DivId integer identity，

    DivName    varchar(100)，

    CONSTRAINT PK_DivisionTable PRIMARY KEY  (DivId)

    )

    create  table  EmployeeTable  (

    EmpId  integer identity，

    DivId  integer not null，

    EmpName    varchar(100)，

    StartDate  DateTime  not  null，

    CONSTRAINT PK_EmployeeTable PRIMARY KEY  (EmpId)，

    CONSTRAINT FK_EmployeeDivision FOREIGN KEY  (DivId)references

DivisionTable(DivId)

    )

    create  table  PositionTable  (

    PosId  integer identity，

    EmpId  integer not null，

    PosName    varchar(100)，

    Level  integer not null，

    CONSTRAINT PK_PositionTable  PRIMARY KEY  (PosId)，

    CONSTRAINT FK_PositionEmployee FOREIGN KEY  (EmpId)references

EmployeeTable(EmpId)

    )

    相应类的概要可被描述为：

    class  Division

    {

       private int id；

       private string name ；

       private EntitySet<Employee>employees ；

       public int DivId

       {

          get  {return id ；}

          set  {id＝value ；}

    }

    public string DivName

    {

       get{return name；}

       set{name＝value；}

    }

    public EntitySet<Employee>Employees

    {

          //用于管理与Employee实例的关系的代码

    }

}

 Division Id可用作外键，DivisionTable(部门表)可用作主键。

class Employee

{

    private int id；

    private string name；

    private EntityRef<Division>division；

    private EntityRef<Position>position；

    public int EmpId

    {

       get{return id；}

       set{id＝value；}

    }

    public string EmpName

    {

       get{return name；}

       set{name＝value；}

    }

    public EntityRef<Division>Division

    {

        //用于管理与Division实例的关系的代码

    }

    public EntityRef<Position>Position

       {

           //用于管理与Position实例的关系的代码

        }

    }

EntitySet(实体集)收集属于一部门的所有雇员。从而，当执行关系世界与对 象世界之间的映射时，部门与雇员之间的双向导航利用Entityset和Entityref(实体 引用)数据对象组件。

    class Position

    {

       private int id；

       private string name；

       private EntityRef<Employee>employee；

       public int PosId

       {

          get{return id；}

          set{id＝value；}

       }

       public string PosName

       {

          get{return name；}

          set{name＝value；}

       }

       public EntityRef<Employee>Employee

       {

          //用于管理与Employee实例的关系的代码

       }

    }

图4和图5示出了在部门与雇员以及在雇员与职位之间维护双向一致性。如 上所述，集或容器可被实现为可对不同类型的对象实例化的通用类，其中集包括一 组对象(例如，一组定单)的聚集。而且，集可包括被称为实体集的一组对象，或 者集可包括对对象的引用(例如，定单的顾客名)——实体引用。一对实体引用可 用来对一对一关系建模。实体引用和实体集的组合可用来对一对多关系建模。

从而并如图6中所示，提供了一种命令性程序设计模型，其中由用户为实体 集采用特定的集合类一般可通过提供双向一致的指针来确保存储器侧102中的对 象图的保真度。例如，可提供雇员部门类(实体集)，使得当用户采用这样的特殊 对象且在630处添加雇员时，雇员部门属性可指回这样的部门，以防止不一致性。 因此，在对象的生命周期期间，可在创建(Create)、读(Read)、更新(Update) 和删除(Delete)(CRUD)操作期间维护这样构建的关系。而且，由于存储器中 的对象存在于堆中，用于感兴趣的对象的表615可提供关于基础架构的根的知识。 这样的感兴趣对象的表可减轻对递归走查(walk)相应图的要求。实体集和实体引 用的指针是双向一致的，以便正确地维护对象关系之间的保真度。对存储器中的对 象的修改然后可被推回到数据库侧606。

数据在关系数据库中情况下的对象图保真度

通常，序列操作符允许对经映射的对象进行查询。查询可指定用于过滤一组 对象的判定。例如，可加载带有特定DivId(部门Id)值的部门对象。一旦对象被 加载之后，重要的是维护它关于进行所指定的映射的持久表示的保真度。保真度保 证允许针对可从给定对象到达的对象图来编写代码，而不必顾及用于检索该对象的 具体查询。也确保对象可用一致的语义来更新。这样的可更新持久对象被称为实体。

一般实施两个约束来确保保真度：

1.维护对象身份：如在大多数对象关系框架的情况中，这可通过维护对应于 实体的主键(或唯一键)值并确保对给定id值不存在一个以上的对象(对给定id 值至多有一个对象引用)来完成；以及

2.确保作为检索到的实体的一部分的实体集合的保真度。从给定实体，实际 上一般应可访问所有相关实体。可以理解，这并不要求所有相关的实体在任何给定 时刻都被加载，而仅要求它们保持可访问。根据本发明的一方面，这是添加到对象 身份的传统ORM机制的新机制。

第二个约束通过要求1∶n关系中1侧的EntitySet来实施。EntitySet通常确保： 首先，当导航相应的关系(如以下代码中)时，EntitySet加载其尚未加载的内容。 内容对应于数据库中的所有目标行的集合。因此，当加载EntitySet div1.Employees 时，数据库中存在的所有对应于Division div1的Employees可被加载。

Division div1＝...

foreach  (div1.Employees中的Employee e)...

其次，EntitySet确保如果目标实体无法加载则考虑指示失败的异常。第三， EntitySet一般从不部分加载。(任何部分加载会引起对象被作为只读、非Entity对 象对待，从而不可由ORM实现更新。开发员能够自由使用服从该规定的部分集合。)

因此，EntitySet确保对对象图保真度。例如，给定一Division实体，例如div1， 它确保div1.Employees一般在检索雇员时从不偏离数据库中该部门的雇员集。 EntitySet机制可被一致地用于惰性(lazy)加载(按需加载)，以及用于急性(eager) 加载(预取)。这两个加载策略具有不同的空间-时间折衷，且适用于不同的数据 改变概况。本发明对这两种加载类型均提供支持而不损害保真度。同样地，EntityRef 提供用于1∶n关系(Employee.Division)中n侧以及1∶1关系(Employee.Position 以及Position.Employee)中两侧的单元素引用的惰性加载能力。惰性加载一般最适 用于：

1.不频繁改变的数据或可容许基于导航在不同时间加载的对象图的部分的应 用程序

2.最小化所加载的数据量——一般仅当访问时才加载EntitySet；否则不加载 急性加载一般最适用于：

1.确保数据的一致快照(例如，Division和Employees被一起加载)。

2.最小化导航的等待时间——EntitySet被预先加载，因此当其被访问时，不 会招致数据库往返航程的等待时间。

EntitySet一般通过加载整个集合来确保惰性加载情况中的保真度。任何失败 被作为异常来报告。同样地，在急性加载的情况中，加载整个EntitySet。也有可能 为对象图中不同的关系使用这两种加载能力的组合。例如，可急性加载 Division.Employees同时惰性加载Employee.Position。

EntitySet限制及其在惰性和急性加载情况中的语义覆盖了对象检索。下一保 真度保证机制处理对检索到的实体的改变以及用于最终插入到数据库中的新实体 的创建。它处理从单向引用构造出的对象图与固有双向的底层的基于值的外键约束 之间的分界。

一般而言，数据库中的给定外键关系可用三种可能的方式之一被映射到类， 这三种方式即：

1.相关类之间的双向引用(例如，上述Division-Employee或Employee-Position 对象模型。)

2.从映射到包含相应外键的表的类出发的单向引用(例如，Employee.Division 存在于对象模型中，但Division.Employee不存在。)

3.从映射到包含相应父键的表的类出发的单向引用(例如，Division.Employee 存在于对象模型中，但Employee.Division不存在。)

在每一情况中，引用可以是公共或私有的，或在对象模型中是显式的或由ORM隐 含(under the cover)实现。

只要对象图中有关系改变，相应的改变必须被保存在包含外键的表中。例如， 如果Employee emp1从Division div1转到Division div2，以上前两种情况可被容易 地转换成emp1的外键改变。在第三种情况中，可能需要搜索来找出在数据库中是 否有Employee行需要被更新。

图7示出了根据本发明的一方面用于修改数据库的示例性方法。尽管示例性 方法此处被显示并描述为一连串表示各种事件和/或动作的框，但本发明不受这样 的框的所示顺序的限制。例如，根据本发明，除此处所示顺序之外，某些动作或事 件可按照不同的顺序发生和/或与其他动作或事件并发。另外，不是所有示出的框、 事件或动作都是实现根据本发明的方法所必需的。而且，可以理解，该示例性方法 和根据本发明的其他方法可与此处所示和描述的方法相关联地实现，以及与未示出 或描述的其他系统和装置相关联地实现。一开始在710，首先将对象带往存储器内 以便在其上执行修改。在720，这可继之以对该对象执行的修改。这样的修改可例 如包括更新、删除，如将在以下详细描述的。例如，其中有两个雇员工作的部门可 被加载到存储器内。雇员可被修改、删除，或另一雇员可被添加到这样的部门。之 后，在730，改变被存回到数据库中。当雇员要被删除时，这可被显式指示。

图8示出了用于删除对象的相关方法。一开始在810，将由一个部门以及与该 部门相关联的两个雇员组成的三个对象检索到存储器中。然后在820，雇员之一可 被删除。在830，这样的删除可被存储到数据库中。这样的删除可被显式指示，例 如：

读取1个div(D1)+2个employees  (E1，E2)

删除E2

保存改变

Division d1＝db.Divisions.Where(d＝＞d.Id＝1).Element().Including(d ＝＞d.Employees)//检索id为1的部门及其雇员(假定两个雇员)

Employee e2＝d1.Employees[1]；//EntitySet Employees中的第 二个雇员

D1.Employees.Remove(e2)；//仅需设置单向引用——另一方向被 自动处理

db.Employees.Remove(e2)；  //标记要删除的雇员

db.PersistChanges()；      //数据保存到数据库中——在数据库 中实现删除

同样地，图9示出了用于更新对象的相关方法。一开始在910，由一个部门和 与该部门相关联的两个雇员组成的三个对象被检索到存储器中。在920，然后雇员 之一可被更新。在830，这样的修改然后可被存储到数据库中。这样的删除可被显 式指示，例如：

读取1个div(D1)+2个employees(E1，E2)

更新E1

保存改变

Division d1＝db.Divisions.Where(d＝＞d.Id＝1).Element().Including(d ＝＞d.Employees)//检索id为1的部门及其雇员(假定两个雇员)

Employee e1＝d1.Employees[0]；//EntitySet Employees中的第 一个雇员

e1.name＝....//改变名字——仅在存储器中改变

db.PersistChanges()；//数据保存到数据库——在数据库中实现更新D

或者，也可采用更显式的表达式db.Employees.TrackChanges(e1)；。

类似地，图10示出了用于插入对象的相关方法。一开始在1010，由一个部门 和与该部门相关联的两个雇员组成的三个对象被检索到存储器中。在1020，然后 可添加一个新的雇员。在1030，这样的修改然后可被保存到数据库中。这样的删 除可被显式指示，例如：

读取1个div(D1)+2个employees(E1，E2)

插入E3

保存改变

Division d1＝db.Divisions.Where(d＝＞d.Id＝1).Element().Including(d ＝＞d.Employees)//检索id为1的部门及其雇员(假定两个雇员)

Employee e3＝new Employee(...)；//所创建的新雇员

e3.Division＝d1；//仅需设置单向引用——另一方向被 自动处理

db.Employees.Add(e3)；//标记要添加的雇员

db.PersistChanges()；//数据被保存到数据库——在数据库 中实现插入

在一个相关方面中，存储器侧所感兴趣的对象的表中的每个对象均有状态。 当添加一对象时，跟踪组件可观察所有相关的项目，且当一对象被标记要删除时， 所有相关的子对象将均被自动删除。而且，当对象被改变时可提供通知，且可保存 未经改变的状态的副本，以便稍后与经修改的版本进行比较。

优化改变检测和原始值跟踪

图11示出了根据本发明的一方面的优化改变跟踪的流程图。一开始在1110， 当调用属性设置器时，生成的代码调用ORM实现以通知对象将要改变。作为响应， 在1120，对象保存(persistence)基础架构检查要改变的对象之前是否已被复制。 如果否，则在1130，对象保存基础架构制作该对象的副本，并在1140将其添加到 要被检查的对象列表。随后在1150，当调用保存改变的API时，查阅经修改对象 的列表来确定经改变对象集合(例如“改变集”)。

一般，以往的ORM实现通常依赖于在检索时对对象制作副本。这样的副本允 许为乐观并发性对原始值的记录保持，并允许当调用保存对象的API时进行改变 检测。本发明的保存基础架构改为利用代码生成期间被注入设置器内的通知机制， 例如未经修改的对象不被复制。这一般可导致大量的空间和时间节省，同时确保乐 观并发性所必需的原始值。而且，当调用保存改变的API时，对象的原始和当前 副本的比较(基于对象身份的“同一性”)对改变检测而言不是必要的。由于通知， 经改变对象的列表随着时间累积。这样可进一步导致改变检测时的大量时间节省。

从而，本发明的对象保存基础架构提供了带有通知机制的用于生成的代码的 优化实现。尽管如此，它也提供用于对象模型的不提供通知的次优和功能上等同的 默认(例如，由开发员编写而非由本发明生成的类)。该基础架构检测通知机制的 缺乏，并主动制作副本以用于乐观并发性和改变检测。因此，可向程序员给出使用 带有命令性框架的代码生成工具的选项，且他们可获得这一优化的好处，或者按需 编写类并丧失这样的优化。因此，可高效使用系统资源。

图12是示出顾客定单关系示例1200的框图，其中顾客数据对象1202可具有 包括对应于定单数据对象1206的对象信息的集合容器1204。类似地，定单数据对 象1206可具有包括对应于顾客数据对象1202的对象信息的引用容器1208。对包 含在集合容器1204中的对象信息的改变可使得向定单数据对象1206发送一通知。 类似地，对包含在引用容器1208中的对象信息的改变可使得向顾客数据对象1202 发送一通知。而且，如图12中所示，跟踪组件1210可增量地创建经改变对象的列 表。

根据本发明的另一方面，跟踪组件1210可在改变发生时检测改变，且仅改变 了的对象的副本才被创建。这样可提供优化检测对对象的改变并维护原始值所需的 空间和时间的优化算法。另外，相应的比较工作可被显著减少。

图13示出了对经改变的对象跟踪以便优化操作的流程图。一开始在1310，根 据本发明的一方面，接收到关于对象改变的通知。在1320，作出关于要被改变的 对象的判断。在1330，制作要被改变的对象的副本。随后，在1340，可对经改变 对象的改变被存回到数据库中。因此，不必递归走查相关联的图，因为经改变对象 是已知的。

用于计算改变集的算法

以下API方法可用于描述用于提交改变的对象保存算法。开发员可通过修改 或删除检索到的对象并创建新持久对象来改变多个持久对象。这样导致创建 (Create)、更新(Update)和删除(Delete)(首字母缩写统称为CUD)操作。

Employees.Add(e1)；//添加Employee实体1以便最终插入到表示数据库中的 EmployeeTable的虚拟表Employees中

Employees.Remove(e2)//从表示数据库中的EmployeeTable的虚拟表 Employees中移除Employee实体e2

SubmitChanges()；//将改变保存到数据库

以下示出了向开发员呈现的使用本发明的框架的CUD操作。

创建新实体

Table.Add(e)//没有原始创建的——等待SubmitChanges()时间，因为在此调用 后e可能被修改

更新检索到的实体

Table.TrackChanges(e)；//复制e，标记要更新

e.Property1＝...

e.Property2＝...

删除检索到的实体

Table.Remove(e)；//对e中的所有实体引用清空并标记e为要删除

Add()(添加)和Remove()(移除)最终导致推迟到执行SubmitChanges()的插入/ 删除操作。

现在，SubmitChanges()进行以下操作：

Tracked::＝Add(e)

         |TrackChanges(e)

-对每一跟踪的实体传递

-找出并标记所引用的“所跟踪”实体，并

-发现添加的新实体。

一般新的顶层实体必须被标记要插入，而非顶层、新实体可被自动发现而不必被标 记。

这样的双头(two-pronged)方法部分为以下理由而实现：

1.新对象链：为每一新创建的Division创建了新Employee，这两者可用一个 调用来方便地处理(这可作为附加的便利存在，但不是必需的。)

2.有时，变量名在调用中不可用；例如如在以下示例中不存在定单的变量名：

var div1＝new Division{

Name＝″...″；

Employees＝{

new Empl oyee{...}，

new Employee{...}

}

    }；

Divisions.Add(div1)；//添加至虚拟表

如上所述地推断对集合的添加，但如果集合的一成员被移除，则由所生成的 代码通知对象保存基础架构(或一般必须由程序员代码来通知)。因此，如果从 div1.Employees移除了一雇员，其中div1为Division，则一般必须在修改之前调用 TrackChanges(div1)。

透明事务模型

事务支持是对象保存基础架构的一个关键方面。现有ORM实现通常提供用于 创建和提交/或退回事务的API。尽管提供事务能力，但API使得它更难以与其他、 非ORM事务(例如，较低级、关系事务API)一起使用。本发明如下解决这样的 复杂性：

1.如果事务是由程序员使用某些其他API来创建的，则它可在该事务的上下 文中执行。

2.否则，对象保存基础架构自动代表程序员启动一事务。它在新创建的事务 的上下文中执行插入/更新/删除SQL，然后适当地提交或退回事务。

第一种方法可与如下所述的API集成，其中“op”指的是表示对象保存实现 的对象。

    using  (TransactionScope  ts  ＝new  ..){

    ...

    //某些事务活动不由对象保存基础架构执行

    cmd.ExecuteReader()；

    //对象保存基础架构使用同一事务——透明地

    op.SubmitChanges()；

    ...

    ts.Complete()；

}

现在参考图14，示出了可在其中实现本发明的各个方面的合适计算环境的简 要、概括描述。尽管以上在运行在一个和/或多个计算机上的计算机程序的计算机 可执行指令的一般上下文中描述了本发明，但本领域的技术人员可以认识到，本发 明也可也与其他程序模块组合来实现。一般，程序模块包括例程、程序、组件、数 据结构等，它们执行特定任务或实现特定抽象数据类型。而且，本领域的技术人员 可以理解，本发明方法可以使用其它计算机系统配置来实现，包括单处理器或多处 理器计算机系统、小型机、大型机、以及个人计算机、手持式计算设备、基于微处 理器或可编程消费者电子产品等。如前所述，本发明的所示方面也可以在分布式计 算环境中实现，其中任务由通过通信网络链接的远程处理设备来执行。然而，即使 不是本发明的全部方面，本发明的某些方面也可在单机计算机上实现。在分布式计 算环境中，程序模块可以位于本地和远程存储器存储设备中。示例性环境包括计算 机1420，它包括处理单元1421、系统存储器1422和将包括但不限于系统存储器的 系统组件耦合至处理单元1421的系统总线1423。处理单元1421可以是任何各种 市场上可购得的处理器。也可以使用双微处理器和其它多处理器体系结构作为处理 单元1421。

系统总线可以是若干类型的总线结构中的任一种，包括USB、1394、外围总 线和使用各种市场上可购得的总线体系结构中的任一种的局部总线。系统存储器可 包括只读存储器(ROM)1424和随机存取存储器(RAM)1425。基本输入/输出 系统(BIOS)包含有助于诸如启动时在计算机1420内元件之间传递信息的基本例 程，它通常被存储在ROM 1424中。

计算机1420还包括硬盘驱动器1427、例如读写可移动盘1429的磁盘驱动器 1428、以及例如读写CD-ROM盘1431或读写其他光介质的光盘驱动器1430。硬 盘驱动器1427、磁盘驱动器1428和光盘驱动器1430可以分别通过硬盘驱动器接 口1432、磁盘驱动器接口1433和光盘驱动器接口1434连接到系统总线1423。驱 动器及其相关联的计算机可读介质为计算机1420提供了对数据、数据结构、计算 机可执行指令等的非易失性存储。尽管以上对计算机可读介质的描述指的是硬盘、 可移动磁盘和CD，但本领域的技术人员应该理解，也可以在示例性操作环境中使 用计算机可读的其它类型的介质，诸如磁带盒、闪存卡、数字视频盘、贝努利盒式 磁带等，而且，任何这样的介质可以包含用于执行本发明的方法的计算机可执行指 令。多个程序模块可被存储在驱动器和RAM 1425中，包括操作系统1435、一个 或多个应用程序1436、其他程序模块1437和程序数据1438。所示计算机中的操作 系统1435可以是基本上市场上可购得的任何操作系统。

用户通过键盘1440和诸如鼠标1442等定点设备向计算机1420输入命令和信 息。其他输入设备(未示出)可包括话筒、操纵杆、游戏手柄、圆盘式卫星天线、 扫描仪等。这些和其它输入设备通常经由耦合至系统总线的串行端口接口1446连 接到处理单元1421，但也可以由其它接口，诸如并行端口、游戏端口或通用串行 总线(USB)连接。监视器1447或其它类型的显示设备也经由接口，诸如视频接 口1448连接至系统总线1423。除监视器以外，计算机一般可以包括其它外围输出 设备，诸如扬声器和打印机。

计算机1420可使用至一台或多台远程计算机，诸如远程计算机1449的逻辑 连接在网络化环境中操作。远程计算机1449可以是工作站、服务器计算机、路由 器、对等设备或其它常见网络节点等，且通常包括以上相对于计算机1420描述的 许多或所有元件，尽管在图14中仅示出存储器存储设备1450。图14中所示逻辑 连接包括局域网(LAN)1451和广域网(WAN)1452。这样的联网环境在办公室、 企业范围计算机网络、内联网和因特网中是常见的。

当在LAN联网环境中使用时，计算机1420可通过网络接口或适配器1453连 接至局域网1451。当在WAN联网环境中使用时，计算机1420通常可包括调制解 调器1454，和/或连接至LAN上的通信服务器，和/或具有用于在诸如因特网等广 域网1452上建立通信的其它装置。调制解调器1452可以是内置或外置的，它可以 通过串行端口接口1446连接至系统总线1423。在网络化环境中，相对于计算机1420 描述的程序模块或其部分可以存储在远程存储器存储设备中。可以理解，所示的网 络连接是示例性的，且可以使用在计算机之间建立通信链接的其它手段。

根据计算机程序设计领域的技术人员的实践，除非另有指示，否则参考由诸 如计算机1420的计算机执行的动作和操作的符号表示描述了本发明。这样的动作 和操作有时被称为计算机执行的。可以理解，动作和用符号表示的操作包括处理单 元1421对表示数据位的电信号的操纵，这导致作为结果的电信号表示的变换或减 少，以及在存储器系统(包括系统存储器1422、硬盘驱动器1427、软盘驱动器1429 和CD-ROM 1431)中的存储器位置处对数据位的维护，从而重新配置或更改计算 机系统的操作以及信号的其他处理。维护这样的数据位的存储器位置是具有对应于 数据位的特定电、磁或光性质的物理位置。

图15示出了可采用本发明的实体集、实体引用安排的客户机-服务器系统 1500。系统1500包括一个或多个客户机1510。客户机1510可以是硬件和/或软件 (例如，线程、进程、计算设备)。系统1500也包括一个或多个服务器1530。由 此，系统1500可对应于两层客户机服务器模型或多层模型(例如，客户机、中间 层服务器、数据服务器)等其他模型。服务器1530也可以是硬件和/或软件(例如， 线程、进程、计算设备)。服务器1530可例如通过采用本发明来容纳执行变换的 线程。客户机1510和服务器1530之间的一种可能的通信可以是适于在两个或多个 计算机进程之间传输的数据包的形式。系统1500包括可以被用来促进客户机1510 和服务器1530之间通信的通信架构1550。客户机1510可操作地连接至可用来存 储对客户机1510本地的信息的一个或多个客户机数据存储1560。类似地，服务器 1530可操作地连接至可被用来存储对服务器1530本地的信息的一个或多个服务器 数据存储1540。

尽管参考若干示出的方面示出并描述了本发明，但本领域的技术人员在阅读 和理解本说明书和附图之后可以想到等效的更改和修改。尤其对于上述组件(程序 集、设备、电路、系统等)执行的各种功能而言，除非另有指定，否则用于描述这 样的组件的术语(包括对“装置”的引用)旨在对应于执行所述组件的指定功能的 任何组件(例如，功能上等效)，即使在结构上不等同于执行此处所示本发明的示 例性方面中的功能的所公开的结构。就此而言，也可认识到，本发明包括含有用于 执行本发明的各种方法的动作和/或事件的计算机可执行指令的系统以及计算机可 读介质。而且，就在详细描述和权利要求书中都使用的术语“包括”、“包含”、 “具有”或“含有”及其变型而言，这些术语旨在以类似于术语“包含”的方式是 包含性的。