系列博客导航：
在上一篇中，我们从理论和概念上详细的了解了LINQ的第二种架构“解释查询”。在这接 下来的二个篇章中，我们将使用LINQ to SQL和Entity Framework来实践“解释查询”，学习这些技术的关键特性。在本系列文章中，我不准备事无巨细的讨论LINQ to SQL和Entity Framework的方方面面，毕竟那样需要太多的篇幅，也会让我们从LINQ上面转移注意力，况且，园子里也有不少介绍LINQ to SQL和Entity Framework的好文章。我们在此关注的是LINQ to SQL和Entity Framework中的”LINQ”部分，并会比较这两种技术的相同和不同之处。通过我们之前介绍的LINQ知识还有将来会讨论的更多LINQ Operators，相信阅者能针对LINQ to SQL和Entity Framework写出优雅高效的查询。为了简单清晰，文中有些地方对LINQ to SQL和Entity Framework进行了缩写，分别为：L2S和EF。
LINQ to SQL和Entity Framework之关联
LINQ to SQL和Entity Framework都是一种包含LINQ功能的对象关系映射技术。他们之间的本质区别在于EF对数据库架构和我们查询的类型实行了更好的解耦。使用EF， 我们查询的对象不再是完全对应数据库架构的C#类，而是更高层的抽象：Entity Data Model。这为我们提供了额外的灵活性，但是在性能和简单性上面也会有所损失。
LINQ to SQL由C#团队开发并在.NET Framework 3.5中发布，而Entity Framework由ADO.NET团队开发并作为.NET Framework 3.5 Service Pack 1的一部分发布。此后，LINQ to SQL由ADO.NET团队接手，其结果是：在.NET 4.0中，ADO.NET团队更加专注于EF的改进，相对来说，LINQ to SQL的改进要小得多。
LINQ to SQL和Entity Framework各有所长，LINQ to SQL是一个轻量级的ORM框架，旨在为Microsoft SQL Server数据库提供快速的应用程序开发，其优点是易于使用、简单、高性能。而Entity Framework的优点在于：其为创建数据库架构和实体类之间的映射提供了更好的灵活性，它还通过提供程序支持除了SQL Server之外的第三方数据库。
EF 4.0一个非常受欢迎的改进是它现在支持与LINQ to SQL几乎同样的查询功能。这意味着我们在系列文章中的LINQ-to-db查询可以同时适用于EF 4.0和L2S。而且，这也使得L2S成为我们学习使用LINQ查询数据库的理想技术，因为其保持了对象关系方面的简单性，并且我们学习到的查询原则和技 术同样适用于EF。
LINQ to SQL实体类
L2S 允许我们使用任何类来表示数据，只要我们为类添加了合适的Attribute（特性）装饰，比如：
[Table] public class Customer { [Column(IsPrimaryKey = true)] public int ID; [Column] public string Name; } [Table] 特性定义在System.Data.Linq.Mapping名字空间中，它告诉L2S该类型的对象代表了数据库表里的一行数据。默认情况下，它假设表名和类名相同，当他们不同时，我们就可以指定具体的表名，如下：
[Table (Name="Customers")]
L2S把这种经过[Table]特性装饰的类成为实体类。一个实体类的结构必须匹配它表示的数据库表，这样才能生成可以正确执行的SQL脚本。
[Column] 特性指定一个字段或属性映射到数据库表的一列，如果列名与字段名/属性名不相同，我们可以指定具体的映射列名：
[Column(Name = "FullName")] public string Name;
我们可以在[Column]特性中指定IsPrimaryKey属性表示该列为表的主键，这对于保持对象标识、往数据库写入更新是必须的。
除了直接定义public字段，我们也可以定义private字段和public属性，这样我们就能在属性存取时加入验证逻辑。此时，为了性能考 虑，我们可以告诉L2S当从数据库存取数据时，绕过属性存取器而直接将值写入private字段。当然，前提是我们认为数据库中的值是正确的，不需要经过 属性存取器中的验证逻辑。
private string name = string.Empty; // Column(Storage = "name") 告诉L2S当从数据库生成实体时直接将数据写入name字段，而不通过set访问器 [Column(Storage = "name")] public string Name { get { return name; } set { if(value.Length > 5) name = value; } } 可以看到，在使用LINQ to SQL时，我们首先要参照数据库的结构来创建各种必须的实体类，这当然不是一种令人愉快的事情。好在，我们可以通过Visual Studio（新增一个”LINQ to SQL Classes” Item）或SqlMetal命令行工具来自动生成实体类。
Entity Framework实体类
和LINQ to SQL一样，Entity Framework允许我们使用任何类来表示数据（尽管我们必须实现特定的接口来完成诸如导航属性等功能）。比如，下面的EF实体类表示一个customer，它被映射到数据库的customer表：
[EdmEntityType (NamespaceName="EFModel", Name="Customer")] public partial class Customer { [EdmScalarProperty(EntityKeyProperty = true, IsNullable= false )] public int ID { get; set; } [EdmScalarProperty(EntityKeyProperty = false, IsNullable = false)] public string Name { get; set; } } 但和L2S不同的是，这样的一个类并不能独立工作。记住：在使用EF时，我们并不是直接查询数据库，而是查询一个更高层的模型，该模型叫做 Entity Data Model(EDM)。所以我们需要某种方法来描述EDM，这通常是由一个以.edmx为扩展名的XML文件来完成的，它包含了一下三个部分：
- 概念模型，用来描述EDM并且和数据库完全隔离
- 存储模型，用来描述数据库架构
- 映射规范，用来描述概念模型如何映射到存储模型
创建一个.edmx文件的最简单方法是在Visual Studio中添加一个”ADO.NET Entity Data Model” 项目，然后按照向导提示来从数据库生成EDM。这种方法不但生成了.edmx文件，还为我们生成了实体类，EF中的实体类对应EDM的概念模型。
设计器为我们生成的EDM初始时包含了表和实体类之间简单的1:1映射关系，当然，我们可以通过设计器或编辑.edmx文件来调整我们的EDM。下面就是我们可以完成的一些工作：
- 映射多个表到一个实体
- 映射一个表到多个实体
- 通过ORM领域流行的三种标准策略来映射继承的类型
这三种继承策略包括：
- 表到层次类型（Table per hierarchy）：单个表映射到一个完整的类继承层次结构。表中的一个类型辨别列用来指示每一行数据应该映射到何种类型。
- 表到类型（Table per type）：单个表映射到单个类型，这意味着继承类型会被映射到多个表。当我们查询一个entity时，EF通过生成SQL JOIN来合并所有的基类型。
- 表到具体类型（Table per concrete type）：单独的表映射到每个具体类型，这意味着一个基类型映射到多个表，当我们查询基类型的entity时，EF会生成SQL UNION来合并数据。
DataContext和ObjectContext
一旦我们定义好了实体类（EF还需定义EDM），我们就可以开始使用LINQ进行查询了。第一步就是通过制定连接字符串来初始化一个DataContext(L2S)或ObjectContext(EF)。
var l2sContext = new DataContext("database connection string"); var efContext = new ObjectContext("entity connection string"); 需要了解的是，直接初始化DataContext/ObjectContext是一种底层的访问方式，但它很好的说明了这些类的工作方式。通常情况下，我们会使用类型化的context（通过继承DataContext/ObjectContext），详细情况稍后就会讨论。
对于L2S，我们传入数据库连接字符串；而对于EF，我们需要传入实体(entity)连接字符串，它同时包含了数据库连接字符串和查找EDM的额 外信息。如果你通过Visual Studio创建了EDM，你会在app.config文件中找到针对该EDM的实体连接字符串，比如：
之后我们就可以通过调用GetTable(L2S)或CreateObjectSet(EF)来获得查询对象。下面的示例使用了我们上面创建的Customer实体类：
var context = new DataContext("Data Source=LUIS-MSFT; Initial Catalog=test; Integrated Security=SSPI;"); Table customers = context.GetTable (); Console.WriteLine(customers.Count()); // 表中的行数 Customer cust = customers.Single(c => c.ID == 1); // 获取ID为1的Customer 下面是EF中的等价代码，可以看到，除了Context的构建和查询对象的获取有所不同，后面的LINQ查询都是一样的：
var context = new ObjectContext(ConfigurationManager.ConnectionStrings["testEntities"].ConnectionString); context.DefaultContainerName = "testEntities"; ObjectSetcustomers = context.CreateObjectSet (); Console.WriteLine(customers.Count()); // 表中的行数 Customer cust = customers.Single(c => c.ID == 1); // 获取ID为1的Customer
一个DataContext/ObjectContext对象有两个作用。其一是工厂作用，我们通过它来创建查询对象，另外，它会跟踪我们对entity所做的任何修改，所以我们可以把修改结果保存到数据库。下面的代码就是更新customer的示例：
// Update Customer with L2S Customer cust = customers.OrderBy(c => c.Name).First(); cust.Name = "Updated Name"; context.SubmitChanges(); // Update Customer with EF, Calling SaveChanges instead Customer cust = customers.OrderBy(c => c.Name).First(); cust.Name = "Updated Name"; context.SaveChanges();
强类型contexts
任何时候都去调用GetTable<>()或CreateObjectSet<>()并不是一件让人愉快的事情，一个更好 的方式是为特定的数据库创建DataContext/ObjectContext的子类，在子类中为各个entity添加属性，这就是强类型的 context，如下：
class LifePoemContext : DataContext { public LifePoemContext(string connectionString) : base(connectionString) { } public Table Customers { get { return GetTable (); } } //... 为其他table创建相应的属性 } // Same thing for EF class LifePoemContext : ObjectContext { public LifePoemContext(EntityConnection connection) : base(connection) { } public ObjectSet Customers { get { return CreateObjectSet (); } } //... 为其他table创建相应的属性 } 之后，我们就可以通过使用属性来写出更加简洁优雅的代码了：
var context = new LifePoemContext("database connection string"); Console.WriteLine(context.Customers.Count()); 如果你是使用Visual Studio来创建”LINQ to SQL Classes”或”ADO.NET Entity Data Model”，它会自动为我们生成强类型的context。设计器同时还会完成其他的工作，比如对标识符使用复数形式，在我们的例子中，它是 context.Customers而不是context.Customer，即使SQL表名和实体类都叫Customer。
对象跟踪/Object tracking
一个DataContext/ObjectContext实例会跟踪它创建的所有实体，所以当你重复请求表中相同的行时，它可以给你返回之前已经创 建的实体。换句话说，一个context在它的生存期内不会为同一行数据生成两个实例。你可以在L2S中通过设置DataContext对象的 ObjectTrackingEnabled属性为false来取消这种行为。在EF中，你可以基于每一种类型进行设置， 如：context.Customers.MergeOption = MergeOption.NoTracking; 需要注意的是，禁用Object tracking同时也会阻止你想数据库提交更新。
为了说明Object tracking，假设一个Customer的名字按字母排序排在首位，同时它的ID也是最小的。那么，下面的代码，a和b将会指向同一个对象：
var context = new testEntities(ConfigurationManager.ConnectionStrings["testEntities"].ConnectionString); Customer a = context.Customers.OrderBy(c => c.Name).First(); Customer b = context.Customers.OrderBy(c => c.ID).First(); Console.WriteLine(object.ReferenceEquals(a, b)); // output: True
这会导致几个有意思的结果。首先，让我们考虑当L2S或EF在遇到第二个query时到底会发生什么。它从查询数据库开始，然后获取ID最小的那一行数据，接着就会从该行读取主键值并在context的实体缓存中查找该主键。如果找到，它会直接返回缓存中的实体而不更新任何值。 所以，如果在这之前其他用户更新了该Customer的Name，新的Name也会被忽略。这对于防止意外的副作用和保持一致性至关重要，毕竟，如果你更 新了Customer对象但是还没有调用SubmitChanges/SaveChanges，你是不会希望你的更新会被另外一个查询覆盖的吧。
第二个结果是在你不能明确把结果转换到一个实体类形，因为在你只选择一行数据的部分列时会引起不必要的麻烦。例如，如果你只想获取Customer的Name时：
// 下面任何一种方法都是可行的 context.Customers.Select(c => c.Name); context.Customers.Select(c => new { Name = c.Name } ); context.Customers.Select(c => new MyCustomerType { Name = c.Name } ); // 但下面这种方法会引起麻烦 context.Customers.Select(c => new Customer { Name = c.Name }); 原因在于Customer实体只是部分属性被获取，这样下一次如果你查询Customer的所有列时，可是context从缓存中返回的的对象只有部分属性被赋值。
关联/Associations
实体生成工具还为我们完成了一项非常有用的工作。对于我们定义在数据库中的每个关联(relationship)，它会在关联的两边添加恰当的属性，让我们可以使用关联来进行查询。比如，假设Customer和Order表存在一对多的关系：
Create table Customer ( ID int not null primary key, Name varchar(30) not null ) Create table Orders ( ID int not null primary key, CustomerID int references Customer (ID), OrderDate datetime, Price decimal not null )
通过自动生成的实体类形，我们可以写出如下的查询：
//获取第一个Custoemr的所有Orders Customer cust1 = context.Customers.OrderBy(c => c.Name).First(); foreach (Order o in cust1.Orders) Console.WriteLine(o.Price); //获取订单额最小的那个Customer Order lowest = context.Orders.OrderBy(o => o.Price).First(); Customer cust2 = lowest.Customer;
并且，如果cust1和cust2正好是同一个Customer时，他们会指向同一对象：cust1 == cust2会返回true。
让我们来进一步查看Customer实体类中自动生成的Orders属性的签名：
// With L2S [Association(Name="Customer_Order", Storage="_Orders", ThisKey="ID", OtherKey="CustomerID")] public EntitySetOrders { get {...} set {...} } // With EF [EdmRelationshipNavigationProperty("testModel", "FK__Orders__Customer__45BE5BA9", "Orders")] public EntityCollection Orders { get {...} set {...} }
一个EntitySet或EntityCollection就如同一个预先定义的query，通过内置的Where来获取相关的entities。 [Association]特性给予L2S必要的信息来构建这个SQL query；[EdmRelationshipNavigationProperty]特性告知EF到EDM的何处去查找当前关联的信息。
和其他类型的query一样，这里也会采用延迟执行。对于L2S，一个EntitySet会在你对其进行枚举时生成；而对于EF，一个EntityCollection会在你精确调用其Load方法时生成。
下面是Orders.Customer属性（位于关联的另一边）：
// With L2S [Association(Name="Customer_Order", Storage="_Customer", ThisKey="CustomerID", OtherKey="ID", IsForeignKey=true)] public Customer Customer { get {...} set {...} } 尽管属性类型是Customer，但它底层的字段（_Customer）却是EntityRef类型的：private EntityRef<Customer> _Customer; EntityRef实现了延迟装载（deferred loading），所以直到你真正使用它时Customer才会从数据库中获取出来。
EF以相同的方式工作，不同的是你必需调用EntityReference对象的Load方法来装载Customer属性，这意味着EF必须同时公开真正的Customer对象和它的EntityReference包装者，如下：
// With EF [EdmRelationshipNavigationProperty("testModel", "FK__Orders__Customer__45BE5BA9", "Customer")] public Customer Customer { get {...} set {...} } public EntityReference CustomerReference 我们也可以让EF按照L2S的方式来工作，当我们设置如下属性后，EF的EntityCollections和EntityReference就会自动实现延迟装载，而不需要明确调用其Load方法。
context.ContextOptions.LazyLoadingEnabled = true;
在下一篇LINQ to SQL和Entity Framework（下）中，我们会讨论学习这两种LINQ-to-db技术的更多细节和值得关注的地方。