思归呓语

自从第一个预览版发布之后，我们一直在奋力增强Code Only功能。

1. 导航属性的倒转（Inverse）关系
2. 属性的细节（Facets），象like Nullability（可null性）, MaxLength（最大长度）, Precision（精度）等等
3. 属性与字段间的映射
4. 类型与数据表间的映射
5. 继承策略
6. 配置的封装

本贴的余下部分将依次对这些特性进行详述。

注册导航属性的倒转关系：

你现在可以注册倒转关系，即一个导航属性到另一个导航属性的倒转（inverse）关系，象这样：

builder.RegisterInverse(
       (Customer c) => c.Orders,
       (Order o) => o.Customer)
);

这代码表示Customer.Orders是Order.Customer关系的另一头。把order1 加到customer1.Orders集合中去，与把order1.Customer设置成customer1具有同等的效果。

指定属性细节（Facets）：

你还可以指定属性的细节，即象Nullability（可null性）, MaxLength（最大长度）, Precision（精度）等等这样的东西，象这样：

var customerConfig = new EntityConfiguration<Customer>();
// 我们可以推断出ID是主键
// 但无法推断出它在插入时是在数据库生成的
customerConfig.ForProperty(c => c.ID)
              .Identity();
customerConfig.ForProperty(c => c.Name)
              .MaxLength(100)
              .NonUnicode();
customerConfig.ForProperty(c => c.Website)
              .MaxLength(200)
              .Nullable()

builder.Configure(customerConfig);

这把Customer类型配置成：

• ID 属性是Identity字段，即在我们插入数据到数据库时，其值是由数据库计算出来的。
• Name属性，其MaxLength为100个字符，是NonUnicode（非Unicode），即在SQL Server中是VARCHAR而不是NVARCHAR。
• Website属性，其MaxLength为200个字符串，是Nullable。

这些细节是针对概念模型Conceptual Model，即CSDL)的，从那里，也传到数据库（即SSDL）。

封装细节配置

你可以创建一个EntityConfiguration<T>的继承类来封装所有这些配置。

例如：

public class CustomerConfig: EntityConfiguration<Customer>
{
    public CustomerConfig(){
       ForProperty(c => c.ID)
                 .Identity();
       ForProperty(c => c.Name)
                 .MaxLength(100)
                 .NonUnicode();
       ForProperty(c => c.Website)
                 .MaxLenght(200)
                 .Nullable();
    }
}

我们建议你创建象这样的类，而不是配置EntityConfiguration<>，因为封装的好处。

指定数据表名

在你使用Configure<T>(..) 时，实体框架为你推断出默认的映射，继承策略(TPH)和表名。

但如果你要指定表名，你可以这么做：

var customerConfig = new EntityConfiguration<Customer>();
// 象上面那样配置细节
...

// 用一个特定的表名注册配置
builder.Tables[“dbo.Custs”] = customerConfig;

指定映射：

如果你需要对映射更多的控制（例如，要映射到一个现有的数据库或者使用企业的命名规则），那么你可以象这样指定映射：

EntityMap<Customer> customerMap = 
    Map.OfType<Customer>(
        c => new {
            cid = c.ID,
            c.Name,
            csite = c.Website
        }
    );

映射解释

这个映射表明，ID是映射到‘cid’字段，Name属性是保存到‘Name’字段，而Website是映射到‘csite’ 字段的。

没有被引用的属性是不会被持久化的，就象使用实体框架默认的代码生成时生成的部分类上的属性一样。

LINQ内涵句法（Comprehension Syntax）

你甚至也可以使用LINQ内涵句法来指定同样的事情：

EntityMap<Customer> customerMap =
    from c in Map.OfType<Customer>()       
    select new {
            cid = c.ID,
            c.Name,
            csite = c.Website
        };

用映射指定细节（Facets）

在配置完映射后，你还可以象这样在映射上指定facets:

customerMap.ForProperty(c => c.ID)
           .Identity();
customerMap.ForProperty(c => c.Name)
           .MaxLength(100)
           .NonUnicode();
customerMap.ForProperty(c => c.Website)
           .MaxLenght(200)
           .Nullable();

指定数据表

最后一步是指派数据表映射。

builder.Tables[“dbo.Custs”] = customerMap;

至此，我们为Customer类指定了自定义表，映射和自定义facets。

指定继承：

CodeOnly默认所用的继承策略是Table Per Hierarchy （每个类分层结构共用一个数据表）(或 TPH)。

但如果你需要一个不同的策略，你需要动手配置相应映射

设想一下，如果你要映射三个类：Vehicle , Car 和 Boat，其中Car 和 Boat是从Vehicle继承而来，而Vehicle本身是个抽象类。

Table Per Hierarchy (TPH，每个类分层结构共用一个数据表)

如果你想要使用TPH做映射，你可以这么做：

var vehicleMap = 
    Map.OfTypeOnly<Vehicle>(
        v => new {
            vid = v.ID,
            v.Name,
            vdesc = v.Description
            v.MaxPassengers,
        }
    ).Union(Map.OfTypeOnly<Car>(
        c => new { 
            vid = c.ID, 
            c.Name,
            vdesc = c.Description 
            c.MaxPassengers,
            trans = c.Transmission,
            tspd = c.Topspeed,
            ccty = c.EngineCapacity,
            ncyld = c.NoCylinder,
            discriminator = “CAR”
        })
    ).Union(Map.OfTypeOnly<Boat>(
        b => new { 
            vid = b.ID, 
            b.Name,
            vdesc = b.Description 
            b.MaxPassengers,
            lng = b.Length,
            b.HasSail,
            b.HasEngine
            discriminator = “BOAT”
        })
    );

builder.Tables[“dbo.vehicles”] = vehicleMap;

在TPH映射中：

1. OfTypeOnly() 用来创建映射片段。
2. 然后，映射片段可以联合（union）起来，这样，它们就可以指派到一个表上（TPH中整个类分层结构共用一个数据表）。
3. 每个非抽象类型需要一个鉴别器字段（discriminator column），该字段可以是任何名称，但类分层结构中的每个非抽象类型必须有一个不同的常数（即“CAR”）。
4. 在映射继承类时，你必须重新映射基类中已经映射了的所有属性。

Table Per Type (TPT，每个类型一个表)

如果你想要使用Table Per Type （每个类型一个表） 或TPT来映射同个类分层结构，你该这么做：

builder.Table[“dbo.Vehicles”]= 
    Map.OfType<Vehicle>(
        v => new {
            vid = v.ID,
            v.Name,
            vdesc = v.Description
            v.MaxPassengers,
        }
    );

builder.Tables[“dbo.Cars”] = 
    Map.OfType<Car>(
        c => new {
            cid = c.ID,
            trans = c.Transmission,
            tspd = c.Topspeed,
            ccty = c.EngineCapacity,
            ncyld = c.NoCylinders,
         }
     );

builder.Tables[“dbo.Boats”] = 
    Map.OfType<Boat>(
        b => new {
            bid = b.ID,
            lng = b.Length,
            b.HasSail,
            b.HasEngine
        }
    );

在TPT映射中：

1. OfType<>()用于每个映射“片段”。
2. 每个映射“片段”指派到不同的表上。
3. 每个映射“片段”只映射在当前类上声明的属性，除非。。。
4. 键属性必须在每个片段中映射（这允许参与该类型的表间的JOIN）。
5. 没有鉴别器字段。

Table Per Class (TPC，每个类一个表，【译注】常规的说法是，每个非抽象类或每个具体类一个表)

你还可以象这样使用TPC来映射这个类分层结构：

builder.Tables[“dbo.Cars”] = 
    Map.OfTypeOnly<Car>(
        c => new {
            cid = c.ID,
            c.Name,
            vdesc = c.Description
            c.MaxPassengers,
            trans = c.Transmission,
            tspd = c.Topspeed,
            ccty = c.EngineCapacity,
            ncyld = c.NoCylinders,
         }
     );

builder.Tables[“dbo.Boats”] = 
    Map.OfTypeOnly<Boat>(
        b => new {
            bid = b.ID,
            b.Name,
            description = b.Description
            b.MaxPassengers,
            lng = b.Length,
            b.HasSail,
            b.HasEngine
        }
    );

在TPC映射中：

1. 跟TPH一样，我们使用OfTypeOnly(..)。
2. 但跟TPH不一样，每个非抽象的类型拥有自己的表（所以，Vehicle没有自己的表，因为它是个抽象类）。
3. 每个映射片段重新映射每个持久（non-transient）属性。
4. 类分层结构中的抽象类没有映射。
5. 没有鉴别器字段。

默认的外键的位置：

如果我们看到一个引用（譬如Order.Customer），我们假定其多重性（multiplicity）为0..1。意即，其外键或FK是可null的。

如果我们看到一个集合（譬如Customer.Orders），我们假定其多重性为多（many）。

然后，在注册倒转（inverse）时，我们知道一个关系的两头的多重性，譬如，在上面的例子中，我们知道，每个Order可以有0..1个 Customer，每个Customer可以有多个Order。

所以按约定，共有三种主要的关系类型，我们需要推断出其FK的位置：

0..1 to many –> 按约定，我们把FK放在many一端，所以上面的Customer.Orders例子中， FK放在Orders 表上。 

many to many –> 没什么选择，只能引进一个连接表（join table）。

0..1 to 0..1 –> 你可以配置FK应该在什么地方，但不配置的话，我们会引进一个连接表（join table）。

但有时候，引用可以不是0..1，而是1，例如，FK（不管它在什么地方），也许不可以null的。

你可以这样来指定FK不是nullable的：

var orderConfig = builder.Configure<Order>();
orderConfig.RegisterInverse(o => o.Customer, c => c.Orders);
orderConfig.ForProperty(o => o.Customer).NonNullable();

这告诉我们，每个Order正好有一个1个Customer，而每个Customer有多个Orders。

能够区分一个引用是非Nullable，会引进几个新的多重性组合，对此，我们也需要约定：

1 to many –> 按约定，我们把FK放在many的一端, 并且在数据库中将其设置为非nullable。

0..1 to 1 –> 按约定，我们把FK放在1的一端, 并且将其设置为非nullable。

1 to 1 –> 跟0..1 to 0..1一样，我们无法决定该把FK放在何处，所以按约定，我们要引进一个连接表（join table）。

指定外键（FK）映射：

至此，我们为实体的属性创建了映射。

那么导航属性和外键怎么办？

所有的关系类型（除了many to many）可以不用数据库中的连接表（join table）来建模，所以我们允许你象这样，作为EntityMap的一部分来映射外键：

EntityMap<Customer> customerMap =
    from c in Map.OfType<Customer>()       
    select new {
            cid = c.ID,
            c.Name,
            csite = c.Website,
            salesPersonFK = c.SalesPerson.ID
        };

customerMap.RegisterInverse(c => c.SalesPerson, s => c.Clients);
builder.Tables[“dbo.Custs”] = customerMap;

这指定，Customer.SalesPerson导航属性，以及它的倒转（inverse）SalesPerson.Customers是保存在 dbo.Custs表的salesPersonFK字段中的。因为映射片段把 salesPersonFK 字段映射到了c.SalesPerson.ID上，而 SalesPerson.ID是相关的SalesPerson实体的主键（或者是主键的一部分），当然，外键是指向主键的。

指定连接表（Join Table）映射：

在many to many关系的情形下，你必须有一个连接表，所以按约定，没有映射信息，我们就会产生一个连接表(join table)。

但假如你需要更多的控制，你可以这么做：

var blogPostsMap = new AssociationMap<Blog, Post>(
     b => b.Posts
).Map(
    (b, p) => new {BlogId = b.ID, PostId = p.ID}
);

builder.Tables[“dbo.BlogPosts”] = blogPostsMap;

这是说， Blog 与 Post间的many to many关系是保存在dbo.BlogPosts表中的，它有2个字段：

• ‘BlogId’ 是个外键，指向Blog的ID属性映射到的字段。
• ‘PostId’ 是个外键，指向Post的ID属性映射到的字段。

分割实体（Entity Splitting）：

Code Only甚至还支持象分割实体这样高级的映射策略：

builder.Tables[“dbo.Customer”] = Map.OfType<Customer>(
   c => new {
      cid = c.ID,
      c.Name,
      active = c.IsActive
   }
);

builder.Tables[“dbo.CustomerDetails”] = Map.OfType<Customer>(
    c => new {
       cid = c.ID,
       c.Size,
       c.Industry
    }
);

这是说，Customer实体是分开保存在dbo.Customer和dbo.CustomerDetails两个表中的。

封装所有的配置：

你还可以编写一个类，从EntityMap<T>继承而来，含有所有的映射，facets等等。例如，下面是一个类，包含了Product的配置：

public class ProductMap: EntityMap<Product>
{
    public ProductMap{
         this.Map( p => new {
              pid = p.ID,
              pcode = p.Name,
              cid = p.Category.ID
         });
         this.ForProperty(p => p.ID).Identity();
         this.ForProperty(p => p.Name).MaxLength(100)
             .NonUnicode();
         this.ForProperty(p => p.Category).NonNullable();
         this.RegisterInverse(p => p.Category,
                              c => c.Products);   
     }
}

这是个高度推荐的做法，因为配置Product类型变得容易之极：

builder.Tables[“dbo.Products”] = new ProductMap();

结束语：

正如你看到的，我们正在计划许多的增强，以允许最核心的场景。

你觉得怎么样？你喜欢这些API么？有什么东西你想要改变的？

一如既往，我们期待听到你的反馈。

Alex James
微软Entity Framework开发团队的Program Manager

本贴是Entity Framework开发团队的透明设计实践的一部分。想了解其工作原理，以及你的反馈是如何被使用的，请参阅 这个贴子。

1. Visual Studio 2010 Beta 1
2. Entity Framework Feature CTP1 (同时参考Entity Framework Feature CTP 1一文，如果你对该CTP中其他特性，特别是POCO模板等，感兴趣的话)
3. 本地的SQL Server 2008 Express或者SQL Server

Code Only全程示范

1) 创建一个名叫“"CodeOnlyWalkthru"”的控制台应用:

2) 往"CodeOnlyWalkThru"解决方案中加一个新的项目：

3) 选择“类库”，将其命名为"Entities"：

4) 在你的Entities项目中加一个"Category"类：

右击Entities项目，加一个名叫“"Category"”的类，然后将下面的代码粘贴入该类：

public class Category
{
    private List<Product> _products;
    public int ID { get; set; }
    public string Name { get; set; }
    public virtual List<Product> Products { 
        get 
        {
            if (_products == null)
                _products = new List<Product>();
            return _products;
        } 
        set 
        { 
            _products = value; 
        } 
    }
}

5) 生成"Product"类：

在"Category.cs"类中，右击还不存在的Product类名，从上下文菜单上选择"Generate > Class（生成类）"：

在新的Product类中，粘贴入下面这些代码：

public class Product
    {
        public int ID { get; set; }
        public string Name { get; set; }
    }

至此，你的项目应该象这样：

我们把这些实体类放进了一个单独的项目，这样它们会被编译进一个对Entity Framework无依赖的程序集中。因此，Entities程序集对持久性是透明的，这对一些开发人员来说，是非常重要的。对持久性有意识的代码存在于另外的程序集中，引用对持久性是透明的程序集。

6) 在"CodeOnlyWalkThru"项目中，添加对Entities项目的引用：

7) 在"CodeOnlyWalkThru"项目中，添加对"System.Data.Entity" 和 "Microsoft.Data.Entity.Ctp"的引用：

注： 从长远看来，我们计划将“Code Only”的功能并入核心的Entity Framework程序集。之后，你就只需第一个引用。

8) 在"CodeOnlyWalkThru" 项目中，加一个新的叫"ProductDBContext"的类：

9) 将下面的代码加到"ProductDBContext"类中：

public class ProductDBContext: ObjectContext
{
    public ProductDBContext(EntityConnection connection)
        : base(connection, "ProductDBContext")
    {
        ContextOptions.DeferredLoadingEnabled = true;
    }
    public IObjectSet<Category> Categories
    {
        get { return CreateObjectSet<Category>(); }
    }
    public IObjectSet<Product> Products
    {
        get { return CreateObjectSet<Product>(); }
    }
}

因为这个类扩充了ObjectContext，它代表你的模型的形状，起通往你的数据库的入口的作用。注意，我们为上面两个实体类型创建了对应的ObjectSet集。 我们还加了一个构造器，它接受一个EntityConnection参数。ContextBuilder会制造一个EntityConnection （EntityConnection封装了实际的数据库连接和Entity Framework元数据（metadata）），在我们要求它生成一个ProductDBContext新实例时，会将该参数传给这个构造器。在构造器中，我们还配置Entity Framework启用DeferredLoading（即LazyLoading-懒式装载）。

10) 然后将下面的代码粘贴进"Program" 类：

SqlConnection connection = new SqlConnection(@"Data Source=.\SQLEXPRESS;Initial Catalog=ProductDB;Integrated Security=SSPI;");
using (ProductDBContext context = ContextBuilder.Create<ProductDBContext>(connection))
{
    if (!context.DatabaseExists())
        context.CreateDatabase();
    Category food = new Category { CID = 1, Name = "Food" };
    Product bovril = new Product { ID = 1, Name = "Bovril" };
    Product marmite = new Product { ID = 2, Name = "Marmite" };
    Product vegemite = new Product { ID = 3, Name = "Vegemite" };
    food.Products.Add(bovril);
    food.Products.Add(marmite);
    food.Products.Add(vegemite);
    context.Categories.AddObject(food);
    context.SaveChanges();
    // Query the database
    food = context.Categories.Single();
    foreach (var product in food.Products)
        Console.WriteLine(product.Name);
}

上面的代码按约定创建了一个上下文，连向本地安装的SQLExpress中的ProductDB数据库。如果ProductDB数据库还不存在，就创建该数据库。

最后，在上下文开始运行后，你就象平常一样使用它，在这个例子中，我们创建了一个Category实例，三个Product实例，两者互相关联，然后我们从数据库中获取Category对象，然后使用LazyLoading（即DeferredLoading），对它的产品进行循环。

就是这么简单！

11) 配置ContextBuilder

迄今为止，我们是按约定来做一切的，因为Code Only可以按约定推断出任何东西。但如果我们将Category类改成象这样的话：

public class Category
{
    private List<Product> _products;
    public int CID { get; set; }
    public string Name { get; set; }
    public virtual List<Product> Products { 
        get 
        {
            if (_products == null)
                _products = new List<Product>();
            return _products;
        } 
        set 
        { 
            _products = value; 
        } 
    }
}

CodeOnly不知道CID是键（key）【见注】，这意味着你需要创建一个ContextBuilder实例，用它来将CID注册成键，象这样：

var builder = new ContextBuilder<ProductDBContext>();
builder.RegisterKey((Category c) => c.CID);

如果需要的话，你可以在同个Builder上注册许多个键，你配置完你的Builder之后，你可以使用它的Create方法来创建一个ProductDBContext实例：

using (ProductDBContext context = builder.Create(connection))

其它的代码没变。

一般来说，在需要创建ObjectContext时，你应该重用你配置的ContextBuilder，而不是每次都重新配置，这会对性能有帮助。最好的做法大概是通过一个静态变量来做。

【注】按约定，任何叫ID, Id, ClassNameID 或 ClassNameId的属性会被假定为实体键。如果找不到这些名称的属性的话，那么你需要调用RegisterKey()，来告诉Entity Framework哪个属性是键。

Beta1版的CTP中Code Only功能的已知限制：

这个版本是一个非常早期的Code Only预览版，因此它有许多已知的限制，我们计划在以后的版本中解决它们，这些限制包括：

• 不支持复杂类型（ComplexType）
• 不支持可配置的映射
• 只支持Table per Hierarchy继承策略
• 不支持Facet的指定，譬如，你无法指定数据库中一个字符串字段的最大长度，而只用默认值
• 没有提供器模型（Provider Model），所以CodeOnly 目前只支持SqlServer
• CodeOnly没有提供方式让你指定哪个属性参与了同个关系，但只是对方的倒转(inverse)。譬如，如果在上面的例子中，你往Product类中加了一个Category属性， 结果在Product和Category间，会有2个关系，因此在Products表中会生成2个外键，因为Entity Framework无法推断Product.Category和Category.Products只是对方的倒转。
• 不支持多对多关系

- Alex James
Entity Framework的Program Manager

如果你一直在关注这个博客的话，你知道我最近在讨论我们加到Entity Framework 4.0中的POCO功能的方方面面，新加的POCO支持促成了在Entity Framework中实现透明性持久的新方式，而该方式在Entity Framework 3.5中是无法实现的。

如果你错过了我的POCO系列，为方便起见，我在下面列了出来，快速浏览一下也许是个不错的主意。

POCO in Entity Framework : Part 1 – The Experience（【翻译】实体框架中的POCO支持 - 第一部分 - 体验 ）

POCO in Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading （【翻译】实体框架中的POCO支持 - 第二部分 - 复杂类型，延迟装载和显式装载 ）

POCO in Entity Framework : Part 3 – Change Tracking with POCO （【翻译】实体框架中的POCO支持 - 第三部分 - POCO的变动跟踪）

在这个贴子里，我想要看一下如何将我们的例子做进一步扩充，使用一些诸如Repository 和 Unit Of Work这样常见的模式，这样我们可以在我们的例子中实现一些特定于持久性的关注。

将我们基于Northwind的例子做一下扩充，譬如说，我有兴趣支持下列与Customer（客户）实体相关的操作：

• 通过ID来查询客户
• 通过名字来查询客户
• 往数据库中加一个新客户

我还想能够基于ID来查询产品。

最后，给定一个客户，我想要能够往数据库中加一个Order（订单）。

在进入细节之前，我想先说明两件事情：

• 处理这个问题，“正确”的方式不止一个。在过程中，我会做许多简化的假设，其目的是展示一幅非常高层次的草图，示范如何实现这2个模式来解决手上的问题。
• 通常来说，在使用TDD时，我会从测试开始，使用我的测试来逐步展开我的设计。因为在这个例子中我没有按TDD做，请耐心点，如果你看到我在做象预先定义接口这样的事情，而不是让测试和共用的东西来主宰接口的必要性，等等。

实现 Repository 模式

让我们先开始实现针对Customer实体的操作，看一下Customer的repository的样子：

public interface ICustomerRepository
{        
    Customer GetCustomerById(string id);
    IEnumerable<Customer> FindByName(string name);
    void AddCustomer(Customer customer);
}

这个repository接口看上去满足有关Customer的所有需求：

• GetCustomerById 应该允许我通过主键来得单个客户实体
• FindByName 应该允许我查询客户
• AddCustomer 应该允许我往数据库中加一个客户

这暂时听上去不错，象这样，为你的repository定义一个接口是个好主意，特别是你对使用mocks(模拟对象） 或 fakes （假冒对象）来编写测试感兴趣的话，接口允许你完全不用考虑数据库，促成更好的单元测试。在将来会有更多的博客贴子讨论可测试性，mocks 和 fakes,等等。

你也许可以进一步扩展这个接口定义，定义一个共用的IRepository，来处理多个repository类型中共有的关注。如果对你有用的话，这是件值得做的事。在这个特定的例子中，我没看到其必要性，所以我就免了。但在你添加更多的repository以及重构时，这完全有可能会变得非常重要。

让我们拿这个repository来看一下如何利用Entity Framework来做一个实现，允许数据访问：

首先，我需要一个可以用来查询数据的ObjectContext。你也许想作为repository构造器的一部分生成一个ObjectContext，但最好还是把那个关注从repository中去除，在别的地方处理为好。

这是我的构造器：

public CustomerRepository(NorthwindContext context)
{
    if (context == null)
        throw new ArgumentNullException("context");

   _context = context;
} 

在上面的代码片段中，NorthwindContext是个我自己的ObjectContext类型。

让我们来提供 ICustomerRepository 接口所需的方法的实现。

GetCustomerById 非常容易实现，多亏了LINQ。使用标准的LINQ运算符，我们可以象这样实现 GetCustomerById ：

public Customer GetCustomerById(string id)
{
    return _context.Customers.Where(c => c.CustomerID == id).Single();
}

类似地，FindByName 可以象这样。 再一次，LINQ支持使得其实现非常容易：

public IEnumerable<Customer> FindByName(string name)
{
    return _context.Customers.Where( c => c.ContactName.StartsWith(name)
                                   ).ToList();                        
}

注意，我选择将结果呈示为IEnumerable<T>，你也许会选择将这呈示为IQueryable<T>。这么做有其含意，在这个情形下，我对呈示建立在repository返回结果之上的基于IQueryable的另外的查询组合，不是很感兴趣。

最后，让我们来看一下可以如何实现AddCustomer：

public void AddCustomer(Customer customer)
{
    _context.Customers.AddObject(customer);
}

你也许想把保存功能作为AddCustomer方法的一部分来实现。那么做也许对这个简单的例子没问题，但一般来说，这不是个好主意，这正是Unit of Work出场的地方，过一会儿，我们会看到如何使用这个模式来允许我们实现和协调Save行为。

这里是使用Entity Framework来处理持久性的CustomerRepository的完整实现：

public class CustomerRepository : ICustomerRepository
{
    private NorthwindContext _context;

    public CustomerRepository(NorthwindContext context)
    {
        if (context == null)
            throw new ArgumentNullException("context");

         _context = context;
    }

    public Customer GetCustomerById(string id)
    {
        return _context.Customers.Where(c => c.CustomerID == id).Single();
    }

    public IEnumerable<Customer> FindByName(string name)
    {
        return _context.Customers.Where(c => c.ContactName.StartsWith(name))
            .AsEnumerable<Customer>();                        
    }

    public void AddCustomer(Customercustomer)
    {
        _context.Customers.AddObject(customer);
    }
}

这里是我们可以如何在客户端代码中使用该repository：

CustomerRepository repository = new CustomerRepository(context);
Customer c = new Customer( ... );
repository.AddCustomer(c);
context.SaveChanges();

在处理与Product和Order相关的需求时，我可以定义下列接口（建造类似CustomerRepository一样的实现）。为简便起见，我把其细节省略了。

public interface IProductRepository
{
    Product GetProductById(int id);
}

public interface IOrderRepository
{
    void AddOrder(Order order);
}

使用ObjectContext实现 Unit of Work （工作单元） 模式

你也许已经注意到了，尽管我们没有实现任何特定的模式来明确地地允许我们将相关操作聚合进一个工作单元（unit of work），但我们已经通过NorthwindContext（我们的ObjectContext类）免费获取了Unit of Work功能。

其想法是，我可以使用Unit of Work将一套相关的操作聚合在一起，Unit of Work记录我感兴趣的变动，直到我准备将它们保存到数据库为止。最终，当我准备保存时，我可以那么做。

我可以象这样定义一个“Unit of Work”接口：

public interface IUnitOfWork
{        
    void Save();
}

注意，在Unit of Work中，你也许还会选择实现Undo / Rollback功能。在使用Entity Framework时，推荐的undo做法是，丢弃你的上下文以及你想undo的变动。

我已经提到，我们的ObjectContext类型(NorthwindContext)在极大程度上支持Unit of Work模式。 基于我刚定义的契约，为了使得事情更为明确一点，我可以将NorthwindContext类改成实现IUnitOfWork接口：

public class NorthwindContext : ObjectContext, IUnitOfWork
{   
    public void Save()
    {
        SaveChanges();
    }

. . . 

在做了这个变动之后，我需要对我们的repository实现做个小的调整：

public class CustomerRepository : ICustomerRepository
{
    private NorthwindContext _context;

    public CustomerRepository(IUnitOfWork unitOfWork)
    {
        if (unitOfWork == null)
            throw new ArgumentNullException("unitOfWork");

        _context = unitOfWork as NorthwindContext;
    }

    public Customer GetCustomerById(string id)
    {
        return _context.Customers.Where(c => c.CustomerID == id).Single();
    }

    public IEnumerable<Customer> FindByName(string name)
    {
        return _context.Customers.Where(c => c.ContactName.StartsWith(name))
            .AsEnumerable<Customer>();
    }

    public void AddCustomer(Customer customer)
    {
        _context.Customers.AddObject(customer);
    }
}

就这么简单！现在，我们有了一个对IUnitOfWork友好的repository，你甚至可以使用基于IUnitOfWork的上下文来协调跨越多个repository的工作。下面是一个将订单加到数据库的例子，需要多个repository的工作来查询数据，最终将记录保存回数据库中去：

IUnitOfWork unitOfWork = new NorthwindContext();

CustomerRepository customerRepository = new CustomerRepository(unitOfWork);
Customer customer = customerRepository.GetCustomerById("ALFKI");

ProductRepository productRepository = new ProductRepository(unitOfWork);
Product product = productRepository.GetById(1);

OrderRepository orderRepository = new OrderRepository(unitOfWork);

Order order = new Order(customer); 
order.AddNewOrderDetail(product, 1);
            
orderRepository.AddOrder(order);

unitOfWork.Save();

非常有趣地看到，为了在Entity Framework之上使用Repository 和 Unit of Work模式来访问数据，我们要编写的代码是如此地少。Entity Framework的LINQ支持以及原装的Unit of Work功能使得在Entity Framework之上建立repository简单之极。

另一个要注意的事情是，我在这个贴子里讨论的很多东西，都不是与Entity Framework 4.0特别有关，所有这些一般原理在Entity Framework 3.5下也适用。但要能够象上面展示的那样，在POCO支持的基础之上，使用Repository 和Unit of Work，确实显示了Entity Framework 4.0中的威力。我希望你会发现这非常有用。

最后，我要重申一下，有很多方式可以处理这个题目，在应用Entity Framework, Repository 和 Unit of Work时，还有许多变种方案可以符合你的需求。你也许会选择实现公共的IRepository接口，你也许还会选择实现Repository<TEntity>基类，来给予你一些跨越所有repository的常用repository功能。

尝试一些方法，看哪个最适用于你。我在这里讨论的只是一般的指南而已，但我希望这足够让你起步。更重要的是，我希望这示范了如何可以使用我们在Entity Framework 4.0中引进的POCO支持，来帮助你建造Entity Framework友好的领域模型，而不必违背透明持久性方面的基本原则。

包含我上面一些示范代码的项目附在本贴之后。在我们的将来贴子中讨论单元测试，TDD和可测试性时，我们还将对这个题目做更多的讨论，敬请期待。

Faisal Mohamood
Entity Framework的Program Manager

在上一个POCO贴子里，我提到了跟踪POCO变动的两种可行性：基于快照的变动跟踪(Snapshot based Change Tracking) 和 使用代理的基于通知的变动跟踪(Notification based Change Tracking with Proxies)。 在这个贴子里，我将对这两个选项做进一步的讨论，讨论它们的优缺点，以及使用它们的含意（implications）。我们还将在《实体框架设计博客》上贴出针对至今为止受到的关于Entity Framework 4.0中POCO支持的一些反馈的想法。

基于快照的变动跟踪（不用代理的纯POCO类）

就象我在这个系列的第二部分中提到的，基于快照（Snapshot）的变动跟踪，就是纯粹的POCO实体的做法，不使用代理来处理变动跟踪。这是个简明的变动跟踪方案，依赖于实体框架所维护的之前和之后值的完整快照，在SaveChanges中对这些值进行比较，决定到底哪些值与初始值有所不同。在这个模型中，除非你用了懒式装载，你的实体的运行时类型跟你定义的POCO实体类型是一模一样的。

这个做法没什么问题，如果你在乎你的实体类型的运行时纯粹性（不使用代理），完全可以依赖这个方案，走纯粹的POCO实体之路（不依赖于代理类型实现额外的功能）。

基于快照的变动跟踪唯一潜在的问题是，有几件事情你需要注意，因为在你的对象变动时没有向实体框架做直接变动通知，实体框架的对象状态管理器将与你的对象图不再同步。

让我们来看一个展示这个问题的例子：

Customer customer = (from c in context.Customers
                     where c.CustomerID == "ALFKI"
                     select c).Single();

ObjectStateEntry ose = context.ObjectStateManager.GetObjectStateEntry(customer);

Console.WriteLine("Customer object state: {0}", ose.State); // Unchanged

customer.Country = "UK";

Console.WriteLine("Customer object state: {0}", ose.State); // Still Unchanged

在这个例子中，Customer是个纯POCO类型，跟基于EntityObject或IPOCO的实体不一样，对该实体做变动并不自动与状态管理器保持同步，因为在你的纯POCO实体与实体框架间没有自动的通知机制。所以，在查询状态管理器时，它会认为你的客户对象的状态是Unchanged（未被改动），尽管我们显式地对该实体的一个属性做了变动。

如果你调用SaveChanges而不选择acceptChangesDuringSave（在保存后接受变动之选项）的话，你会看到在保存后，其状态变成了Modified（改动过了）。这是因为在保存时，基于快照的变动跟踪机制开始起作用，检测到了变动。当然，默认的SaveChanges调用会将状态变回到 Unchanged ，因为默认的Save行为是在保存后接受变动。

在后面一点，我们将进一步讨论在你需要让你的对象，对象图以及状态管理器间保持同步时该怎么做，但让我们先来看一下可为你所用的POCO的另一类变动跟踪机制。

使用代理的基于通知的变动跟踪

如果你在乎在你对实体值，关系和对象图做变动时的非常高效的和即时性的变动跟踪的话，这是个另样的方案，基于代理的变动跟踪。如果你把某个特定实体类型上的所有映射属性都声明为virtual的话，你就可以利用基于代理的变动跟踪了。

使用代理来跟踪变动的实体总是与实体框架的对象状态管理器保持同步，因为代理会在实体的值和关系变动时通知实体框架。总的来说，这使得变动跟踪更为有效，因为对象状态管理器可以略去比较属性的原始值和当前值这一步，如果它知道属性没有变动的话。

实际上，你从代理上得到的变动跟踪行为跟从基于EntityObject的非POCO实体或IPOCO实体上得到的变动跟踪行为是完全一样的。

让我们用同一个例子来看一下：

Customer customer = (from c in context.Customers
                     where c.CustomerID == "ALFKI"
                     select c).Single();

ObjectStateEntry ose = context.ObjectStateManager.GetObjectStateEntry(customer);

Console.WriteLine("Customer object state: {0}", ose.State); // Unchanged

customer.Country = "UK";

Console.WriteLine("Customer object state: {0}", ose.State); // Modified

这个例子是不言自明的，在你对实体做变动时，对象状态管理器被通知到你的变动了。在调用SaveChanges时，不会导致另外的花销（overhead）。

但是，基于代理的变动跟踪也意味着你的实体的运行时类型跟你定义的类型不完全一样，而是你的类型的子类。这在许多场景下（譬如序列化）也许不太合适，你需要选择在你的应用和领域的需求和约束下最合适的方法。

不使用代理，与状态管理器保持同步

两种方法都有其优缺点，但不是基于代理的纯POCO方案，其之简明和优雅也意味着它会成为你们中许多人的默认选择，也就毫不奇怪了。所以让我们来看一下在这种模式下，如何使状态管理器与你的对象图保持同步。

ObjectContext.DetectChanges()

在你使用基于快照的纯POCO实体时，有一个至关重要的方法：ObjectContext.DetectChanges()。

这个API在你无论何时改变对象图时都应该显式调用，它会告知状态管理器它需要与的你对象图做同步。

ObjectContext.SaveChanges在默认情形下会隐式调用DetectChanges，所以，如果你所做的就是对你的对象们做一系列的变动，然后立刻调用Save的话，你不必显式调用DetectChanges。但是，要记住的是，取决于你的对象图的大小，DetectChanges也许会花销很大（而且，取决于你在做什么，DetectChanges也许是多余的），所以，有可能你可以略去SaveChanges中隐式调用的DetectChanges，这一点，在我们讨论Entity Framework 4.0中新引进的SaveChanges的重载方法时会做更多的讨论。

让我们来看一下DetectChanges如何影响我们前面看过的例子：

Customer customer = (from c in context.Customers
                     where c.CustomerID == "ALFKI"
                     select c).Single();

ObjectStateEntry ose = context.ObjectStateManager.GetObjectStateEntry(customer);

Console.WriteLine("Customer object state: {0}", ose.State); // Unchanged

customer.Country = "UK";
Console.WriteLine("Customer object state: {0}", ose.State); // Still Unchanged

context.DetectChanges();
Console.WriteLine("Customer object state: {0}", ose.State); // Modified

显式调用DetectChanges 会导致状态管理器与你的对象的状态保持一致。

因为DetectChanges的潜在花销，依赖于状态管理器与对象图保持一致的ObjectContext上的其他一些APIs是不显式调用它的。因此，无论什么时候你在context上做依赖于状态的操作时，你需要调用DetectChanges。

Object Servces（对象服务）中的下列API的行为取决于ObjectStateManager的当前状态，因此，如果它们操作的部分对象图的情况与对象图的实际状态不同步的话，会受影响：

ObjectContext API:

• AddObject
• Attach
• AttachTo
• DeleteObject
• Detach
• GetObjectByKey
• TryGetObjectByKey
• ApplyCurrentValues
• ApplyPropertyChanges
• ApplyOriginalValues
• Refresh
• ExecuteQuery

ObjectStateManager API:

• ChangeObjectState
• ChangeRelationshipState
• GetObjectStateEntry
• TryGetObjectStateEntry
• GetObjectStateEntries

ObjectStateEntry API:

• Any

EntityCollection/EntityReference API:

• Any

SaveChanges的新重载方法

在Entity Framework 3.5中, 在调用ObjectContext.SaveChanges()时，有两种可能:

• SaveChanges() – 无参数选项，允许你保存变动，同时隐式接受变动。
• SaveChanges(bool acceptChangesDuringSave) – 这个选项允许你跳出默认的“accept changes during save”（保存时同时接受变动）行为，你需要在保存后显式地使用AcceptAllChanges来接受变动。

在加了DetectChanges行为后，再加另外的重载方法很明显会搞乱API。为了解决这个问题，引进了SaveOptions这个列举标记：

[Flags]
public enum SaveOptions
{
    None = 0,
    DetectChangesBeforeSave = 1,
    AcceptChangesAfterSave = 2,
}

SaveChanges现在包括了象这样一个重载：

public virtual int SaveChanges(SaveOptions options);

SaveOptions将允许我们（Entity Framework开发团队）以可控制得多的方式来扩展API，假如我们需要在将来添加另外的选项的话。

但这个重载的有趣性还有另外一个原因：注意，这个SaveChanges重载是virtual。在Entity Framework 4.0中，你可以用你自己的定制行为，作为你选择编写的ObjectContext的继承类的一部分，来覆盖SaveChanges行为。无论你是否使用Entity Framework中的POCO支持，这将允许你以一种Entity Framework 3.5中不可能的方式来做定制。

至此，我想要重点阐述的Entity Framework 4.0中有关POCO的事情几乎都说完了，请接着期待下一篇在Entity Framework中使用模式的贴子。

Faisal Mohamood
Entity Framework开发团队的Program Manager