目录
Entity Framework的核心 – EDM(Entity Data Model) 7
为什么要使用Entity Framework，限制条件及当前版本框架的问题 23
本文档主要介绍.NET开发中两项新技术，.NET平台语言中的语言集成查询技术 - LINQ，与ADO.NET中新增的数据访问层设计技术ADO.NET Entity Framework。ADO.NET的LINQ to Entity部分以LINQ为基础，为了完整性本文档首先介绍LINQ技术。
预备知识
LINQ技术
LINQ是.NET 3.5中新增的一种技术，这个技术扩展了.NET平台上的编程语言，使其可以更加方便的进行数据查询，单纯的LINQ技术主要完成对集合对象（如System.Collection下或System.Collection.Generic命名空间下的对象）的查询。结合LINQ Provider可以实现对XML文件（使用LINQ to XML – 位于System.Xml.Linq命名空间下的类），数据库（可以使用LINQ to SQL或下文要详细介绍的LINQ to Entity）等对象的操作。
LINQ是一种运行时无关的技术，其运行于CLR2.0之上，微软对C#3.0与VB9.0的编译器进性扩展，从而使其可以将LINQ编写的程序编译为可以被CLR2.0的JIT所理解的MSIL。
LINQ技术的基础 - C#3.0
-
自动属性
-
隐式类型
-
对象集合初始化器
-
匿名类
-
扩展方法
-
Lambda表达式
自动属性
这个概念很简单，其简化了我们在.NET的时候手写一堆私有成员+属性的编程方式，我们只需要使用如下方式声明一个属性，编译器会自动生成所需的成员变量。
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
}
在我使用LINQ完成的项目中，使我了解到自动属性方便的一个用途如下：
在使用LINQ获取数据的过程中，我们常常需要使用select new语句查询出一个对象（往往是IEnumerable类型的）用于数据绑定。在一般情况下如果是直接绑定（如直接将查询结果赋给一个Gridview控件的DataSource属性）我们可以直接select new来返回一个匿名类的对象。如果我们还需要对这个集合对象进行进一步操作，我们将必须使用select new class-name这样的语言返回一个类的对象，大部分情况下这个类只作为实体的一个结构而不需要完成一些操作操作，这时候使用自动属性来完成这个类将是非常简洁高效的。
隐式类型
这个名称可能对你很陌生，但是var这个关键字应该都用过，在C#中使用var声明一个对象时，编译器会自动根据其赋值语句推断这个局部变量的类型。赋值以后，这个变量的类型也就确定而不可以再进行更改。另外var关键字也用于匿名类的声明。
应用场合：var主要用途是表示一个LINQ查询的结果。这个结果可能是ObjectQuery<>或IQueryable<>类型的对象，也可能是一个简单的实体类型的对象。这时使用var声明这个对象可以节省很多代码书写上的时间。
对象初始化器与集合初始化器
在.NET2.0中构造一个对象的方法一是提供一个重载的构造函数，二是用默认的构造函数生成一个对象，然后对其属性进行赋值。在.NET3.5/C#3.0中我们有一种更好的方式来进行对象的初始化。那就是使用对象初始化器。这个特性也是匿名类的一个基础，所以放在匿名类之前介绍。
还是那就话，好的代码强于注释，下面用几个代码段说明初始化器：
（代码出自：李永京的博客 http://lyj.cnblogs.com）
基本用法：
User user = new User { Id = 1, Name = "YJingLee", Age = 22 };
嵌套使用：
User user = new User
{
Id = 1,
Name = "YJingLee",
Age = 22,
Address = new Address
{
City = "NanJing",
Zip = 21000
}
};
类似于对象初始化器初始化一个对象，集合初始化器初始化一个集合，一句话，有了它你就不用在将元素通过Add逐个添加了。仍然给出代码示例：
基本使用：
List<int> num = new List<int> { 0, 1, 2, 6, 7, 8, 9 };
结合对象初始化器，我们可以写出如下简洁的代码：
List<User> user = new List<User>{
new User{Id=1,Name="YJingLee",Age=22},
new User{Id=2,Name="XieQing",Age=25},
};
应用场合：
还是前文提到的select new class-name语法，后面可以直接接一个初始化器来将查询结果返回到这个对象。
匿名类
有了前文初始化器的介绍，匿名类就很简单了。我们可以使用new { object initializer }或new[]{ object, …}来初始化一个匿名类或不确定类型的数组。匿名类的对象需要使用var关键字声明。示例代码：
var p1 = new { Id = 1, Name = "YJingLee", Age = 22 };
应用场合：
还是同上面的例子提到的当直接使用select new { object initializer }这样的语法就是将一个LINQ查询的结果返回到一个匿名类中。
扩展方法
扩展方法是C#中新增的很重要的特性之一。其对于LINQ的实现起着关键的作用。在.NET2.0时代是没有LINQ的，所以.NET2.0以及之前版本中的集合类在设计的时候没有预留用于LINQ的方法。为了在不破坏这个类现有封装的前提下又可以为其添加LINQ的支持就需要用到扩展方法。
扩展方法使用上类似于静态方法，但在本质上其是实例方法。这是由于.NET3.5的运行环境仍然为CLR2.0所以语言不可能做很大的变革，这一切都是语法糖。
下面仍然通过一段代码来说明扩展方法的实现：
（代码出自：李永京 http://lyj.cnblogs.com）
public static class Extensions
{
public static bool IsValidEmailAddress(this string s)
{
Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");
return regex.IsMatch(s);
}
}
如上代码所示，扩展方法为一静态方法，声明于一个静态类，其参数前加上一个this关键字，参数的类型表示这个扩展方法要对这个类型进行扩展。如上述代码表示其要对字符串类型进行扩展。
在应用上扩展方法被作为其扩展的类型的静态方法来调用。如下：
if (email.IsValidEmailAddress())
{
Response.Write("YJingLee提示:这是一个正确的邮件地址");
}
Lambda表达式
Lambda表达式是对.NET2.0中匿名方法在语法形式上的进一步改进，仍然以代码说明：
var inString = list.FindAll(delegate(string s) { return s.Indexof("YJingLee") >= 0; });
使用Lambda表达式代码将更自然易懂。
var inString = list.FindAll(s => s.Indexof("YJingLee") >= 0);
可以看出，Lambda表达式格式为：(参数列表)=>表达式或语句块
另外我对于Lambda表达式树的概念还不是很明白，有明白的指点一下。
.NET中的数据访问
这一部分介绍.NET中不同的数据访问层的使用方式，由此得出Entity Framework在一个.NET系统中的应用及其在原有设计基础上的改变。从大的方面来看数据访问的设计方案基本有如下几类：
-
DataSet
-
手写代码通过ADO.NET2.0连接类与数据库交互
-
ORM组件
DataSet方案
最基本的Dataset数据访问的实现使用下图表示：
图1
如图所示，DataSet与数据源之间通过DataAdapter连接，逻辑中直接访问DataSet获取数据，或是通过ADO.NET2.0的非连接类，或者通过强类型DataSet以一种类型安全的方式访问数据。
缺点逻辑代码与数据访问代码耦合高。
改进的的DataSet方案
图2
这种设计方式将业务所需的实体抽象出来，并把对DataSet的操作封装在其中，这样一定程序上解除业务逻辑与数据访问间的耦合。
手写代码通过ADO.NET2.0连接类与数据库交互
这种方式是我使用的最多的一种方式，其可以提供最大的控制能力，且效率最高，唯一的不足是当业务变化时修改数据访问代码的工作量比较大，通过代码生成器也能一定程度上解决这个问题
ORM – LINQ to SQL
在.NET平台下ORM的解决方案有不少，本文只讨论两个微软官方的解决方案。先是LINQ to SQL技术。LINQ to SQL是一个将不再更新的技术。其有很多不足之处，如，不能灵活的定义对象模型与数据表之间的映射、无法扩展提供程序只能支持SQL Server等。
这样数据访问层的设计如下所示：
图3
ORM – ADO.NET Entity Framework
作为下一代数据访问的技术领导者。Entity Framework的设计很多地方都保留了高扩展性。其最重要的一个改进在于其映射定义的灵活性。先来看下图：
图4
由图可以看出，使用Entity Framework可以充分的定义与数据库表映射的实体，并将这个实体直接用于业务逻辑层或作为服务的数据契约。实体设计较其他技术的优势体现在以下几方面：
-
创建ComplexType（CSDL部分有讨论）
-
EntitySet的继承
使用Entity Framework后，可以将实体类的设计工作完全放在EDM的设计过程中，而不再需要手工写一些大同小异的代码，并且对这个实体模型（包含于EDM中）可以在运行时修改并生效。另外，开发人员与数据库直接打交道的次数将大大减少，大部分时间开发人员只需操作实体模型，框架会自动完成对数据库的操作。下文将详细讨论上图所示的EDM。
深入了解Entity Framework
Entity Framework的核心 – EDM(Entity Data Model)
EDM概述
实体数据模型，简称EDM，由三个概念组成。概念模型由概念架构定义语言文件 (.csdl)来定义，映射由映射规范语言文件 (.msl)，存储模型（又称逻辑模型）由存储架构定义语言文件 (.ssdl)来定义。这三者合在一起就是EDM模式。EDM模式在项目中的表现形式就是扩展名为.edmx的文件。这个包含EDM的文件可以使用Visual Studio中的EDM设计器来设计。由于这个文件本质是一个xml文件，可以手工编辑此文件来自定义CSDL、MSL与SSDL这三部分。下面详细分析一下这个xml文件及三个其重要组成部分：
这个文件展示了示例项目完整的EDM文件的XML形式：
这个设计器生成的文件的注释可以使你很清楚的明白这个EDM文件的组成。一点点分析一下，第一行表明这是一个xml文件。
|
<?xmlversion="1.0"encoding="utf-8"?> |
以下这一行是EDM的根节点，定义了一个表明版本的属性及这个EDM使用的命名空间：
|
<edmx:EdmxVersion="1.0"xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx"> |
接下来由注释可以看到EDM被分为两部分，第一部分是EDM的核心，第二部分用于实体设计器，这一部分不用研究。
第一部分中节点<edmx:Runtime>下定义了以下三部分：
EDM之CSDL
CSDL定义了EDM或者说是整个程序的灵魂部分 – 概念模型。当前流行的软件设计方法通常都是由设计其概念模型起步。说概念模型可能比较抽象一个更容易接受的名字就是实体类。实体类是面向对象设计中一个最根本的组成部分，其体现了现实世界中对象作为一种计算中可以表示的对象设计方法。而EDM的CSDL就是要达到这样一个目的。这个在下文介绍Entity Framework优点时另有说明。
这个文件完全以程序语言的角度来定义模型的概念。即其中定义的实体、主键、属性、关联等都是对应于.NET Framework中的类型。下面xml element来自作业提交系统（有删节）：
|
<!-- CSDL content --> <edmx:ConceptualModels> <SchemaNamespace="ASSModel"Alias="Self"xmlns="http://schemas.microsoft.com/ado/2006/04/edm"> <EntityContainerName="ASSEntities"> <FunctionImportName="GETHOUSEWORKDONE"EntitySet="UpAssignments"ReturnType="Collection(Self.UpAssignments)"> <ParameterName="StuID"Type="Int32"Mode="In" /> <ParameterName="ClassID"Type="Int32"Mode="In" /> <ParameterName="Semester"Type="String"Mode="In" /> </FunctionImport> <!--以上删节 – 5个存储过程--> <EntitySetName="Assignments"EntityType="ASSModel.Assignments" /> <EntitySetName="Classes"EntityType="ASSModel.Classes" /> <EntitySetName="Courses"EntityType="ASSModel.Courses" /> <EntitySetName="SetCourses"EntityType="ASSModel.SetCourses" /> <EntitySetName="Students"EntityType="ASSModel.Students" /> <EntitySetName="Teachers"EntityType="ASSModel.Teachers" /> <EntitySetName="UpAssignments"EntityType="ASSModel.UpAssignments" /> <AssociationSetName="FK_SetCourses_Classes"Association="ASSModel.FK_SetCourses_Classes"> <EndRole="Classes"EntitySet="Classes" /> <EndRole="SetCourses"EntitySet="SetCourses" /> </AssociationSet> <!--以上删节 – 6个关系集--> </EntityContainer> <!--以下保留一个EntityType作为示例--> <EntityTypeName="Students"> <Key> <PropertyRefName="StuID" /> </Key> <PropertyName="StuID"Type="Int32"Nullable="false" /> <PropertyName="StuName"Type="String"Nullable="false"MaxLength="10"Unicode="true"FixedLength="true" /> <PropertyName="Pswd"Type="String"Nullable="false"MaxLength="50"Unicode="false"FixedLength="true" /> <NavigationPropertyName="Classes"Relationship="ASSModel.FK_Students_Classes"FromRole="Students"ToRole="Classes" /> <NavigationPropertyName="UpAssignments"Relationship="ASSModel.FK_UpAssignments_Students"FromRole="Students"ToRole="UpAssignments" /> </EntityType> <!--仅保留与上文AssociationSet对应的Association --> <AssociationName="FK_SetCourses_Classes"> <EndRole="Classes"Type="ASSModel.Classes"Multiplicity="1" /> <EndRole="SetCourses"Type="ASSModel.SetCourses"Multiplicity="*" /> </Association> </Schema> </edmx:ConceptualModels> |
这部分XML文档，Schema是CSDL的根元素，其中定义的Namespace是用于ObjectContext与EntityClass的命名空间，Alias-别名为此命名空间Namespace指定一个易记的名称，在定义Alias之后，在此Schema内的Element均可以该Alias作为Namespace的别名。Alias的使用可以参考如下xml element:
|
<FunctionImportName="GETHOUSEWORKDONE"EntitySet="UpAssignments"ReturnType="Collection(Self.UpAssignments)"> |
在这个根元素的内部的文档结构第一部分 – 实体容器大致如下：
|
<EntityContainer /> <FunctionImport /> <EntitySet /> <AssociationSet /> </EntityContainer> |
下面的表格说明了这些节点及其属性的作用
|
EntityContainer |
|||
|
Name |
EntityContainer的名称，其将作为产生的ObjectContext类的名称 |
||
|
EntitySet |
|||
|
Name |
ObjectContext内与此Entity类型对应的属性名 |
||
|
EntityType |
ObjectContext内与此Entity类型对应的属性的类型 |
||
|
AssociationSet |
|||
|
End |
有两个End子节点，分别描述建立此关系的两个EntitySet |
||
|
Role |
对应到Association中End节的Role属性，起到将AssociationSet与Association相关连的作用。 |
||
|
FunctionImport |
详见存储过程设计部分 |
||
可以看出，Entity与Assciation都被分开定义与两个部分，这样设计是出于当有多个EntityContainer时，其中的EntitySet或AssociationSet可以共享Entity或Association的定义。
接下来看一下CSDL中最后一部分，Entity与Association的定义。
首先是Entity：
<EntityTypeName="Students">
<Key>
<PropertyRefName="StuID" />
</Key>
<PropertyName="StuID"Type="Int32"Nullable="false" />
<PropertyName="StuName"Type="String"Nullable="false"MaxLength="10"Unicode="true"FixedLength="true" />
<PropertyName="Pswd"Type="String"Nullable="false"MaxLength="50"Unicode="false"FixedLength="true" />
<NavigationPropertyName="Classes"Relationship="ASSModel.FK_Students_Classes"FromRole="Students"ToRole="Classes" />
<NavigationPropertyName="UpAssignments"Relationship="ASSModel.FK_UpAssignments_Students"FromRole="Students"ToRole="UpAssignments" />
</EntityType>
下表说明了其属性及其子节点与子节点的属性的含义：
|
EntityType |
|||
|
Name |
Entity Class的名称 |
||
|
Abstract |
是否为抽象类 |
||
|
BaseType |
父类 |
||
|
Key |
主键 |
||
|
Property |
主键之属性 |
||
|
Name |
属性名 |
||
|
Property |
属性 |
||
|
Name |
属性名 |
||
|
Type |
属性类型 |
||
|
Nullable |
是否允许null |
||
|
MaxLength |
属性最大长度 |
||
|
FixLength |
是否固定长度 |
||
|
NavigationProperty |
关系属性 |
||
|
Name |
属性名 |
||
|
Relationship |
对应的Association |
||
|
FromRole、ToRole |
区别关系两方的父与子 |
||
最后Association节，这是真正定义关系的地方。首先看示例：
<!--仅保留与上文AssociationSet对应的Association -->
<AssociationName="FK_SetCourses_Classes">
<EndRole="Classes"Type="ASSModel.Classes"Multiplicity="1" />
<EndRole="SetCourses"Type="ASSModel.SetCourses"Multiplicity="*" />
</Association>
这一节符合以下结构：
|
<Association> <End /> <ReferentialConstraint> <Principal> <PropertyRef /> </Principal> <Dependent> <PropertyRef /> </Dependent> </ReferentialConstraint> </Association> |
属性及其子元素属性的说明：
|
Association |
||||
|
Name |
Association的名称 |
|||
|
End |
类似于AssociationSet，Association也有两个End节点。 |
|||
|
Name |
End名称 |
|||
|
Type |
EntityType的名称 |
|||
|
Role |
此End的Role，与AssociationSet的End的Role属性相联系 |
|||
|
Multiplicity |
关联多重性，值为0、1或* |
|||
|
ReferentialConstraint |
外键条件限制 |
|||
|
Principal |
主要条件 |
|||
|
Role |
对应于End中的Role |
|||
|
PropertyRef |
外键属性 |
|||
|
Name |
属性名称 |
|||
|
Dependent |
依存条件 |
|||
|
Role |
对应于End中的Role |
|||
|
PropertyRef |
外键属性 |
|||
|
Name |
属性名 |
|||
另外上面示例未涉及的概念，如下：
视图
在EDM设计器中添加视图基本与添加实体表一致，所生成的xml自行对照。某些环境下可能无法添加视图，原因未知，另外对于没有主键的表目前版本EntityFramework支持不好，在设计器中无法添加，及时通过手工编辑xml的方式强行添加，在使用过程中也会出现问题。
ComplexType（复杂类型）
按MSDN中的例子，先描述如下场景。在一个销售系统中我们需要在一个订单中包含一个描述客户地址的实体，而这个实体又能良好的与存储模型映射起来，由于数据库不支持地址这种类型，所以我们可以将地址的每个字段与数据库相映射。且在概念模型中，及在C#代码可以控制的范围内，地址仍然作为一个独立的类型存在。由于EDM设计器不支持以可视化方式创建Complex Type，我们需要手动编辑CSDL与MSL来完成复杂类型的创建与映射。这部分示例将在介绍MSL后给出。
EDM之SSDL
这个文件中描述了表、列、关系、主键及索引等数据库中存在的概念。
|
<!-- SSDL content --> <edmx:StorageModels> <SchemaNamespace="ASSModel.Store"Alias="Self"Provider="System.Data.SqlClient"ProviderManifestToken="2008"xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator"xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl"> <EntityContainerName="ASSModelStoreContainer"> <EntitySetName="Assignments"EntityType="ASSModel.Store.Assignments"store:Type="Tables"Schema="dbo" /> <!--省略7个EntitySet的定义--> </EntityContainer> <!--以下省略7个EntityType的定义--> <EntityTypeName="Assignments"> <Key> <PropertyRefName="AssID" /> </Key> <PropertyName="AssID"Type="int"Nullable="false"StoreGeneratedPattern="Identity" /> <PropertyName="AssName"Type="nchar"Nullable="false"MaxLength="20" /> <PropertyName="AssDes"Type="nvarchar"MaxLength="500" /> <PropertyName="SCID"Type="int"Nullable="false" /> <PropertyName="Deadline"Type="datetime"Nullable="false" /> <PropertyName="QuesFileName"Type="nvarchar"MaxLength="500" /> <PropertyName="QuesFileUrl"Type="nvarchar"Nullable="false"MaxLength="500" /> </EntityType> <!--保留与CSDL中对应的Function --> <FunctionName="GETHOUSEWORKDONE"Aggregate="false"BuiltIn="false"NiladicFunction="false"IsComposable="false"ParameterTypeSemantics="AllowImplicitConversion"Schema="dbo"> <ParameterName="StuID"Type="int"Mode="In" /> <ParameterName="ClassID"Type="int"Mode="In" /> <ParameterName="Semester"Type="varchar"Mode="In" /> </Function> </Schema> </edmx:StorageModels> |
看文档的结构，SSDL与CSDL很详细，只是其中EntityType等使用数据库的概念的描述。
这其中有一个需要稍微介绍节点，DefiningQuery，首先看一下其出现的位置：
|
EntityContainer |
||||
|
EntitySet |
||||
|
DefiningQuery |
通过查询定义一个SSDL的EntitySet |
|||
|
特定于存储的查询语句 |
||||
DefiningQuery定义通过实体数据模型 (EDM) 内的客户端投影映射到数据存储视图的查询。此类映射是只读的。也就是说如果想要更新此类EntitySet，需要使用下文介绍存储过程时提到的定义更新实体的存储过程的方法，使用定义的存储过程来更新这样的EntitySet。当在实体类设计器中导入无主键的表时，会自动生成此类使用DefiningQuery定义的EntitySet，要式样Entity Framework提供的自动更新服务而不定义存储过程，需要给数据表添加一个适当的主键，删除DefiningQuery节点并更新数据模型。
EDM之MSL
这个文件即上面所述的CSDL与SSDL的对应，主要包括CSDL中属性与SSDL中列的对应。
|
<!-- C-S mapping content --> <edmx:Mappings> <MappingSpace="C-S"xmlns="urn:schemas-microsoft-com:windows:storage:mapping:CS"> <EntityContainerMappingStorageEntityContainer="ASSModelStoreContainer"CdmEntityContainer="ASSEntities"> <EntitySetMappingName="Assignments"> <EntityTypeMappingTypeName="IsTypeOf(ASSModel.Assignments)"> <MappingFragmentStoreEntitySet="Assignments"> <ScalarPropertyName="QuesFileName"ColumnName="QuesFileName" /> <ScalarPropertyName="AssDes"ColumnName="AssDes" /> <ScalarPropertyName="AssID"ColumnName="AssID" /> <ScalarPropertyName="AssName"ColumnName="AssName" /> <ScalarPropertyName="Deadline"ColumnName="Deadline" /> <ScalarPropertyName="QuesFileUrl"ColumnName="QuesFileUrl" /> </MappingFragment> </EntityTypeMapping> </EntitySetMapping> <!--省略EntitySetMapping若干--> <!--保留对应于CSDL与SSDL的FunctionImportMapping --> <FunctionImportMappingFunctionImportName="GETHOUSEWORKDONE"FunctionName="ASSModel.Store.GETHOUSEWORKDONE" /> <AssociationSetMappingName="FK_UpAssignments_Assignments"TypeName="ASSModel.FK_UpAssignments_Assignments"StoreEntitySet="UpAssignments"> <EndPropertyName="Assignments"> <ScalarPropertyName="AssID"ColumnName="AssID" /> </EndProperty> <EndPropertyName="UpAssignments"> <ScalarPropertyName="UpAssID"ColumnName="UpAssID" /> </EndProperty> </AssociationSetMapping> <!--省略AssociationSetMapping若干--> </EntityContainerMapping> </Mapping> </edmx:Mappings> |
如上代码所示，MSL的根节点为Mapping，其中可以包含多个EntityContainerMapping（上例只有一个），每一个EntityContainerMapping对应着两个分别来自CSDL与SSDL的EntityContainer。这个EntityContainerMapping就是描述这两个EntityContainer间的对应。下面再给出一段代码展示EntityContainerMapping的基本格式。
|
<EntityContainerMappingStorageEntityContainer=""CdmEntityContainer=""> <EntitySetMapping> <EntityTypeMapping> <MappingFragment> <ScalarProperty /> </MappingFragment> <ModificationFunctionMapping> <InsertFunction /> <DeleteFunction /> <UpdateFunction /> </ ModificationFunctionMapping> </EntityTypeMapping> </EntitySetMapping> <AssociationSetMapping> <EndProperty> <ScalarProperty /> </EndProperty> </AssociationSetMapping> <FunctionImportMapping /> </EntityContainerMapping> |
同上文，下面列出这些节点的属性
|
EntityContainerMapping |
||||||
|
StorageEntityContainer |
SSDL中的EntityContainer名称 |
|||||
|
CdmEntityContainer |
CSDL中的EntityContainer名称 |
|||||
|
EntitySetMapping |
EntityContainer中每个EntitySet的对应 |
|||||
|
Name |
EntitySetMapping的名称 |
|||||
|
EntityTypeMapping |
描述CSDL中EntityType与SSDL中EntityType的对应 |
|||||
|
Name |
EntityTypeMapping的名称 |
|||||
|
TypeName |
对应CSDL内Entity的名称 – 格式：IsTypeOf(<名称>) 注：这个类及其子类将共享此EntityTypeMapping |
|||||
|
MappingFragment |
描述属性及字段间的对应 |
|||||
|
StoreEntitySet |
SSDL中的EntitySet名称 （由于CSDL中一个EntitySet可以对应多个SSDL中的EntitySet） |
|||||
|
ScalarProperty |
属性与字段对应 |
|||||
|
Name |
CSDL中的属性名 |
|||||
|
ColumnName |
SSDL中的字段名称 |
|||||
|
Condition |
详见说明2 |
|||||
|
ColumnName |
列名 |
|||||
|
Value |
值 |
|||||
|
ModificationFunctionMapping |
CUD对应的存储过程 |
|||||
|
InsertFunction/ UpdateFunction / DeleteFunction |
||||||
|
FunctionName |
||||||
|
QueryView |
||||||
|
Entity SQL |
||||||
|
AssociationSetMapping |
描述CSDL中的AssociationSet与SSDL中的EntitySet的对应关系 |
|||||
|
Name |
AssociationSetMapping的名称 |
|||||
|
StoreEntitySet |
SSDL中EntitySet的名称 |
|||||
|
TypeName |
CSDL中AssociationSet的名称 |
|||||
|
EndProperty |
一个AssociationSetMapping中有两个EndProperty 分别对应CSDL中两个End Role |
|||||
|
Name |
EndProperty的名称 |
|||||
|
ScalarProperty |
关系属性对应 |
|||||
|
Name |
CSDL中的属性名 |
|||||
|
ColumnName |
SSDL中的字段名称 |
|||||
|
ModificationFunctionMapping |
C/D对应的存储过程 |
|||||
|
InsertFunction/ DeleteFunction |
||||||
|
FunctionName |
||||||
|
QueryView |
||||||
|
EntitySQL |
||||||
|
FunctionImportMapping |
用于描述CSDL与SSDL间函数及函数参数的对应（详见下文存储过程部分） |
|||||
说明1：以上表中很重要的一个属性是MappingFragment中的StoreEntitySet属性，就像这个属性的说明中所说，其描述了CSDL的Entity对应到的SSDL的Entity的名称。这是实现下文EDM映射方案中第二条将一个概念模型的实体映射到多个存储模型的实体的关键设置。
说明2：Contain这个元素及其属性的作用是，当多个概念模型实体映射到一个存储模型实体时，该元素的属性决定了在什么情况下一个概念模型实体映射到指定的存储模型实体。
说明3：QueryView 元素定义概念模型中的实体与存储模型中的实体之间的只读映射。使用根据存储模型计算的 Entity SQL 查询定义此查询视图映射，并以概念模型中的实体表达结果集。同DefiningQuery定义的查询。此映射也是只读的。就是说如果想要更新此类EntitySet，也需要使用下文介绍存储过程时提到的定义更新实体的存储过程的方法，使用定义的存储过程来更新这样的EntitySet。当多对多关联在存储模型中所映射到的实体表示关系架构中的链接表时，必须为此链接表在AssociationSetMapping 元素中定义一个QueryView元素。定义查询视图时，不能在 AssociactionSetMapping 元素上指定 StorageSetName 属性。定义查询视图时，AssociationSetMapping 元素不能同时包含 EndProperty 映射。
EDM中存储过程的设计
目前版本(VS2008SP1)的实体设计器对存储过程支持不完善，只能手工编辑这三个文件中的存储过程部分，包括：
-
CSDL中的FunctionImport元素，其属性及说明如下所示：
FunctionImport
Name
（在程序中调用的）函数的名称
EntitySet
当函数返回实体对象时，需使用此属性指定对应的EntitySet
ReturnType
函数返回值的类型
Parameter
以下用于参数子节点中的属性定义
Name
参数的名称
Type
参数的类型
Mode
参数的传递方式(In, Out或InOut)
MaxLength
参数值最大长度
Precision
参数值的精确度，用于数字类型
Scale
浮点数小数位
-
SSDL中的Function节
Function
Name
存储过程名称
Aggregate
是否为聚合函数（存储过程）
BuiltIn
是否为内建存储过程
NiladicFunction
是否为无参数存储过程
IsComposable
True为自定义函数，False为存储过程
ParameterTypeSemantics
参数类型转换方式
ReturnType
存储过程返回类型
-
MSL中的FunctionImportMapping节
FunctionImportMapping
FunctionImportName
CSDL中FunctionImport的名称
FunctionName
SSDL中Function Element的名称
这面总结的是用于返回实体对象的查询（存储过程）。
下面分别描述一下有关修改操作的存储过程的使用：
-
使用插入、更新或删除实体数据的存储过程，需要修改如下两个文件： SSDL，对其的修改要求与上文表中列出的一致：
MSL，需要对一下节点进行定义：
|
EntityContainerMapping |
|||||
|
EntitySetMapping |
EntityContainer中每个EntitySet的对应 |
||||
|
EntityTypeMapping |
描述CSDL中EntityType与SSDL中EntityType的对应 |
||||
|
ModificationFunctionMapping |
CUD对应的存储过程 |
||||
|
InsertFunction/ UpdateFunction / DeleteFunction |
|||||
|
FunctionName |
|||||
-
使用创建或删除在数据源中使用链接表实现的实体类型之间的多对多关系的存储过程需要修改如下两个文件： SSDL，对其的修改要求与上文表中列出的一致：
MSL，需要对一下节点进行定义：
|
EntityContainerMapping |
||||
|
AssociationSetMapping |
描述CSDL中的AssociationSet与SSDL中的EntitySet的对应关系 |
|||
|
ModificationFunctionMapping |
C/D对应的存储过程 |
|||
|
InsertFunction/ DeleteFunction |
||||
|
FunctionName |
||||
EDM中ComplexType的设计
再谈Complex Type，上文大致介绍了复杂类型的概念及作用，现在开始看一下具体怎样实现。前文已经提到实现复杂类型关键是在CSDL与MSL，而与SSDL无关。
首先应该在CSDL中怎加这样一节，此节与<EntityType></EntityType>节同级，其结构如下：
|
<ComplexType> <Property /> </ComplexType> |
节点及其属性含义如下：
|
ComplexType |
复杂类型 |
|
|
Name |
复杂类型的名称 |
|
|
Property |
属性 |
|
|
Name |
属性名 |
|
|
Type |
属性类型 |
|
|
Nullable |
是否允许null |
|
|
MaxLength |
属性最大长度 |
|
|
FixLength |
是否固定长度 |
|
然后在MSL中<MappingFragment>下与<ScalarProperty />同级的位置添加如下节：
|
<ComplexProperty> <ScalarProperty /> </ComplexProperty> |
具体的节及其属性含义如下：
|
ComplexProperty |
复杂类型属性 |
|
|
Name |
复杂类型属性名称 |
|
|
TypeName |
CSDL中定义的ComplexType的名称。格式"CSDN_Namespace.ComplexTypeName" |
|
|
ScalarProperty |
关系属性对应 |
|
|
Name |
CSDL中的属性名 |
|
|
ColumnName |
SSDL中的字段名称 |
|
实体数据模型映射方案
实体框架支持各种方式用于在实体数据模型 (EDM) 中将概念模型映射到关系数据。有关更多信息，请参见 实体框架中的数据建模。
实体框架当前支持以下实体数据模型 (EDM) 映射方案。
|
编号 |
映射方案 |
说明 |
|
1 |
简单映射 |
在此映射方案中，概念模型中的每个实体都映射到存储模型中的单个表。这是实体数据模型工具所生成的默认映射。 |
|
2 |
实体拆分 |
在此映射方案中，概念模型中单个实体的属性映射到两个或更多基础表中的列。在此方案中，表必须共享公共主键。 其设计方式见EDM之MSL部分说明1。 |
|
3 |
存储模型中的水平分区 |
在此映射方案中，概念模型中的单个实体类型映射到具有相同架构的两个或更多表。实体基于概念模型中定义的条件映射到表中。 使用场合：使一个概念模型的实体映射到不同数据源的存储模型的实体。 另见：EDM之MSL部分说明2。 |
|
4 |
概念模型中的水平分区 |
在此映射方案中，概念模型中具有相同属性的多个实体类型映射到同一个表。条件子句用于指定表中的数据分别属于哪个实体类型。此映射类似于类型5。 这种方式也用到MSL中的Conditon来决定映射关系，见EDM之MSL部分说明2。 |
|
5 |
每个层次结构一个表继承 |
在此映射方案中，继承层次结构中的所有类型都映射到同一个表。条件子句用于定义实体类型。 见EDM之MSL部分说明2。 |
|
6 |
每种类型一个表继承 |
在此映射方案中，所有类型都分别映射到各自的表。仅属于某个基类型或派生类型的属性存储在映射到该类型的一个表中。 |
|
7 |
每种具体类型一个表继承 |
在此映射方案中，每个非抽象类型分别映射到不同的表。所有这些表所包含的列必须映射到派生类型的所有属性（包括从基类型继承的属性）。 |
|
8 |
每种类型多个实体集 |
在此映射方案中，单个实体类型在概念模型中以两个或更多独立的实体集进行表示。每个实体集分别映射到存储模型中的一个单独的表。 其设计方式见EDM之MSL部分说明1。 |
|
9 |
复杂类型 |
复杂类型是没有键属性的实体类型的非标量属性。复杂类型可以包含其他嵌套的复杂类型。复杂类型映射到存储模型中的表。 复杂类型在上文有单独介绍 |
|
10 |
函数导入映射 |
在此方案中，存储模型中的存储过程映射到概念模型中的 FunctionImport 元素。执行此函数可使用映射的存储过程返回实体数据。 见上文存储过程部分 |
|
11 |
修改函数映射 |
在此方案中，在存储模型中定义用于插入、更新和删除数据的存储过程。这些函数是为实体类型定义的，以便为特定实体类型提供更新功能。 见上文存储过程部分 |
|
12 |
定义查询映射 |
在此方案中，在存储模型中定义表示数据源中的表的查询。在映射到 SQL Server 数据库时，查询以数据源的本机查询语言（如 Transact-SQL）表示。此 DefiningQuery 元素映射到概念模型中的实体类型。查询以特定于存储的查询语言进行定义。 上文EDM之SSDL部分最后详细介绍了这种设计的相关问题 |
|
13 |
查询视图映射 |
在此方案中，会在概念模型中的实体类型与存储模型中的关系表之间定义只读映射。此映射基于对存储模型进行的 Entity SQL 查询定义。 上文EDM之MSL中说明三对这种设计的相关问题有介绍。 |
|
14 |
AssociationSet 映射 |
关联定义实体之间的关系。在具有一对一或一对多关联的简单映射中，在概念模型中定义关系的关联会映射到存储模型中的关联。还支持以下更高级的关联集映射： 多对多关联。关联的两端都映射到存储模型中的链接表。 自关联。此映射支持具有相同类型的两个实体之间的关联，如一个 Employee 与另一个 Employee 之间的关联。 派生类型之间的关联。此映射支持一个层次结构中的派生类型与另一个层次结构中的派生类型之间的关联。 |
Entity Framework的原理及使用方式
ADO.NET Entity Framework操作数据库的过程对用户是透明的（当然我们可以通过一些工具或方法了解发送到数据库的SQL语句等）。我们唯一能做的是操作EDM，EDM会将这个操作请求发往数据库。
Entity Framework实现了一套类似于ADO.NET2.0中连接类（它们使用方式相同，均基于Provider模式）的被称作EntityClient的类用来操作EDM。ADO.NET2.0的连接类是向数据库发送SQL命令操作表或视图，而EntityClient是向EDM发送EntitySQL操作Entity。EntityClient在EntityFramework中的作用是相当重要的，所有发往EDM的操作都是经过EntityClient，包括使用LINQ to Entity进行的操作。
各种使用方式总结
上文提到对EDM的操作，首先通过一个图来展现一下目前我们可用的操作的EDM的方式：
这几种访问方式使用介绍如下：（部分示例代码来源MSDN Magzine）
-
EntityClient+EntitySQL
示例代码：
string city = "London";
using (EntityConnection cn = new EntityConnection("Name=Entities"))
{
cn.Open();
EntityCommand cmd = cn.CreateCommand();
cmd.CommandText = @"SELECT VALUE c FROM Entities.Customers AS c WHERE
c.Address.City = @city";
cmd.Parameters.AddWithValue("city", city);
DbDataReader rdr = cmd.ExecuteReader(CommandBehavior.SequentialAccess);
while (rdr.Read())
Console.WriteLine(rdr["CompanyName"].ToString());
rdr.Close();
}
-
ObjectService+EntitySQL
在有EntityClient+EntitySQL这种使用方式下，使用ObjectService+EntitySQL的方式是多此一举，不会得到任何编辑时或运行时的好处。在ObjectContext下使用EntitySQL的真正作用是将其与LINQ to Entity结合使用。具体可见下文所示。
示例代码：
string city = "London";
using (Entities entities = new Entities())
{
ObjectQuery<Customers> query = entities.CreateQuery<Customers>(
"SELECT VALUE c FROM Customers AS c WHERE c.Address.City = @city",
new ObjectParameter("city", city)
);
foreach (Customers c in query)
Console.WriteLine(c.CompanyName);
}
-
ObjectContext+LINQ( to Entity)
方式一：
string city = "London";
using (Entities entities = new Entities())
{
var query = from c in entities.Customers
where c.Address.City == city
select c;
foreach (Customers c in query)
Console.WriteLine(c.CompanyName);
}
方式二：
string city = "London";
using (Entities entities = new Entities())
{
var query = entities.Customers.Where(r => r.Address.City == city);
foreach (Customers c in query)
Console.WriteLine(c.CompanyName);
}
这两段示例代码中的entities.Customer的写法隐式调用了2中示例的ObjectQuery<Customers>来进行查询（关于此可以参见EDM的设计器文件-xxx.designer.cs）。在方式二中的Where方法传入的是一个Lambda表达式，你也可以传入一条EntitySQL语句做参数来将LINQ与EntitySQL结合使用。如下代码演示其使用：
string city = "London";
using (Entities entities = new Entities())
{
var query = entities.Customers.Where("r.Address.City = '"+city+"'");
foreach (Customers c in query)
Console.WriteLine(c.CompanyName);
}
使用技巧及需要注意的问题
这也是上文提到的在ObjectContext下使用EntitySQL的一个主要作用，上面的例子比较简单可能看不到这样使用的优势，但是如下两种情况下使用EntitySQL可能是最好的选择。
-
动态构建查询条件 当查询条件的个数固定时，我们也可以采用罗列多个Where扩展方法的形式，如下：
ObjectQuery.Where(LambdaExpression1) .Where(LambdaExpression2)…
但是当这个条件的存在与否需要在运行时判断时，我们只能通过组合字符串来得到这个条件，我们可以将条件组合为EntitySQL并传递给Where()方法。
-
数据库模糊查询
下面代码演示使用EntitySQL的like完成模糊查询：
|
context.Customer.Where("it.CustomerID LIKE @CustomerID", new System.Data.Objects.ObjectParameter("CustomerID","%V%")); |
这个并不是只能使用EntitySQL来实现，LINQ to Entity也可以很容易完成。如下代码：
|
context.Customer.Where(r => r.CustomerID.Contains("V")); |
同理，"V%"、"%V"可以分别使用StartsWith()与EndsWith()函数实现。
使用LINQ to Entity需要注意的一个方面是，在完成查询得到需要的结果后使用ToList或ToArray方法将结果转变为内存中的对象，然后使用LINQ to Objects来处理，否则处在Entity Framework的联机模式下对性能有很大的影响。
几种方法的性能分析及使用选择
首先用下图来说明一个执行过程。
图中所示表达的意思已经非常清楚，稍加解释的是，无论是通过EntityClient直接提供给Entity Client Data Provider的Entity SQL还是通过ObjectService传递的Entity SQL（或是LINQ to Entity），都在Entity Client Data Provider中被解释为相应的Command Tree，并进一步解释为对应数据库的SQL。这样来看使用LINQ to Entity与Entity SQL的效率应该差不多，但是还有一个问题，那就是EntitySQL所转换的最终SQL可能要比LINQ to Entity生成的SQL效率高，这在一定程度上使两者效率差增大，但是LINQ to Entity有其它技术无法比拟的好处，那就是它的强类型特性，编辑时智能感知提醒，编译时发现错误，这都是在一个大型项目中所需要的。虽然现在也有了调试EntitySQL的工具，但其与强类型的LINQ to Entity还是有很大差距。
另外在ObjectService与直接使用EntityClient问题的选择上。如果你想更灵活的控制查询过程，或者进行临时查询建议选择EntityCLient，如果是操作数据那只能采用ObjectService。
上文总结了各种操作EDM的方式，下面引用MSDN的一个对这几种技术进行比较的表格：
|
EntityClient 和实体 SQL |
对象服务和实体 SQL |
对象服务和 LINQ |
|
|
定向到 EntityClient 提供程序 |
是 |
否 |
否 |
|
适合临时查询 |
是 |
是 |
否 |
|
可直接发出 DML |
否 |
否 |
否 |
|
强类型化 |
否 |
否 |
是 |
|
可将实体作为结果返回 |
否 |
是 |
是 |
通过这个表可以很好对某一场合下应该选择的技术进行判断。EntityClient 和实体 SQL可以进行最大的控制，而使用LINQ to Entity可以获得最佳的编辑时支持。
其它操作EDM的方式
通过EdmGen更灵活的控制EDM
在.NET Framework 3.5的文件夹下有一个名为EdmGen的工具，Visual Studio的实体设计器就是调用这个工具来完成EDM的生成等操作。通过直接使用这个工具的命令行选项我们可以进行更多的控制。
这个命令的参数及作用如下：
|
EdmGen 选项 /mode:EntityClassGeneration 从 csdl 文件生成对象 /mode:FromSsdlGeneration 从 ssdl 文件生成 msl、csdl 和对象 /mode:ValidateArtifacts 验证 ssdl、msl 和 csdl 文件 /mode:ViewGeneration 从 ssdl、msl 和 csdl 文件生成映射视图 /mode:FullGeneration 从数据库生成 ssdl、msl、csdl 和对象 /project:<字符串> 用于所有项目文件的基名称 (短格式: /p) /provider:<字符串> 用于 ssdl 生成的 Ado.Net 数据提供程序的名称。(短格式: /prov) /connectionstring:<连接字符串> 您要连接到的数据库的连接字符串 (短格式: /c) /incsdl:<文件> 从中读取概念模型的文件 /refcsdl:<文件> 包含 /incsdl 文件所依赖的类型的 csdl 文件 /inmsl:<文件> 从中读取映射的文件 /inssdl:<文件> 从中读取存储模型的文件 /outcsdl:<文件> 将生成的概念模型写入到其中的文件 /outmsl:<文件> 将生成的映射写入到其中的文件 /outssdl:<文件> 将生成的存储模型写入到其中的文件 /outobjectlayer:<文件> 将生成的对象层写入到其中的文件 /outviews:<文件> 将预生成的视图对象写入到其中的文件 /language:CSharp 使用 C# 语言生成代码 /language:VB 使用 VB 语言生成代码 /namespace:<字符串> 用于概念模型类型的命名空间名称 /entitycontainer:<字符串> 用于概念模型中的 EntityContainer 的名称 /help 显示用法信息 (短格式: /?) /nologo 取消显示版权消息 |
使用示例：
从 Northwind 示例数据库生成完整 Entity Model。
|
EdmGen /mode:FullGeneration /project:Northwind /provider:System.Data.SqlClient /connectionstring:"server=.\sqlexpress;integrated security=true; database=northwind" |
从 ssdl 文件开始生成 Entity Model。
|
EdmGen /mode:FromSSDLGeneration /inssdl:Northwind.ssdl /project:Northwind |
验证 Entity Model。
|
EdmGen /mode:ValidateArtifacts /inssdl:Northwind.ssdl /inmsl:Northwind.msl /incsdl:Northwind.csdl |
为什么要使用Entity Framework，限制条件及当前版本框架的问题
-
优势
通过对比上面图4与图2、图3我们可以很清楚的看到使用Entity Framework一个很大的好处，我们可以把实体类的定义由一个单独的项目使用C# class完成这样一种设计方式转变为使用xml文件定义并集成到数据访问层。
在以往要在一个项目中动态创建实体，我所知的方法是把要添加的实体放入一个程序集，然后通过反射加载程序集。现在可以通过动态更改EDM的方法来增加实体并将其映射到数据库，后者是以前无法实现的。
便于更改数据库，当更换数据库后，只需修改SSDL的定义，（如果数据库的表明有变动，也只需多修改MSL），对CSDL没有任何影响，从而也不需要对程序的BLL等上层部分做任何改动。
-
条件
要想让一个数据库支持Entity Framework，一个必要条件就是该数据库需提供相应的Entity Client Data Provider，这样才能将Entity SQL转换为针对此数据此数据库的SQL并交由ADO.NET来执行。当然该数据库还需要提供ADO.NET Data Provider。
-
缺陷
Entity Framework技术的效率问题是其几乎唯一一个稍有不足之处。首先其将EntitySQL转换为SQL的方式属于解释性转换，性能较差。另外Entity Framework在每次应用启动时需要读取EDM，这个过程较慢（但在后续操作时，就不再存在这个问题）。
EDM中的DML
由于当前的EntitySQL不支持DML操作，所以当前版本的Entity Framework的插入、更新及删除操作需要通过Object Service来完成。在EDM的设计器文件xxx.designer.cs中自动生成了一些签名为
void AddToEntity(EntityType entity)
的方法。我们只需要新建一个实体对象并调用这个方法添加实体即可。注意这个函数内部调用
entities.AddObject("EntitySetName", entity);
最后调用entities.SaveChanges()方法将修改保存回数据库，这是所有三种更新操作所需的。更新与删除操作都需要先使用ObjectService定位操作的实体对象，更新操作直接使用赋值运算符，删除操作则调用
entites.DeleteObject(object o);
方法。之后调用entities.SaveChanges()方法保存，这个过程简单，不再赘述。
含有Association的EDM的使用
当前版本的Entity Framework不支持自动延迟加载，所有当前未使用的关系中的相关实体默认按不加载处理，当我们需要通过关系获取一个实体对象时，我们可以采用两种方法：
-
显示加载 实体框架针对 EntityReference 类的每个实例提供一个 Load 方法。此方法可用于显式加载与另一实体相关的一个集合。我们只需在访问关系中实体之前调用其Load即可，当然提前判断该实体是否已经加载是一种比较好的实践。如下代码所示
using (Entities entities = new Entities())
{
var query = (from o in entities.Orders
where o.Customers.CustomerID == "ALFKI"
select o);
foreach (Orders order in query)
{
if (!order.CustomersReference.IsLoaded)
order.CustomersReference.Load();
Console.WriteLine(order.OrderID + " --- " +
order.Customers.CompanyName);
}
}
-
预先加载
先看代码示例
using (Entities entities = new Entities())
{
var query = (from o in entities.Orders.Include("Customers")
where o.ShipCountry == "USA"
select o);
foreach (Orders order in query)
Console.WriteLine(order.OrderID + " --- " +
order.Customers.CompanyName);
}
查询中针对 Orders 实体调用的 Include 方法接受了一个参数，该参数在本示例中将要求查询不仅要检索 Orders，而且还要检索相关的 Customers。这将生成单个 SQL 语句，它会加载满足 LINQ 查询条件的所有 Order 和 Customer。
两种加载关系实体的方式的选择根据：如果针对关系数据你只需做一到两次查询，则使用显示加载更高效，如果要持续访问关系实体中数据，则使用预先加载。
关系下的添加，更新与删除与上述操作基本相同，唯一需要注意的是删除操作不支持级联删除，需要手工遍历所有的相关项并将其一一删除。注意这里删除操作不能使用foreach来遍历需要删除的关系实体。取而代之的有两种方法：
-
while法
while (result.Order_Details.Count > 0)
{
// 删除操作…
}
-
ToList法（以非联机方式操作）
var items = result.Order_Details.ToList();
foreach (var item in items)
{
// 删除操作…
}
最新补充
Entity Framework在开发中的应用 – Entity Framework与控件
.NET Framework提供了许多xxxDataSource控件，如SqlDataSource，ObjectDataSource等，这些数据源控件大大方便了我们的数据绑定操作。不幸的是目前还没有针对Entity Framework的数据源控件发布，但是将数据绑定到诸如ListBox，Grrdview或DetailsView控件也是很简单的。这源于使用ObjectContext操作返回的IQueryable<T>对象或是使用EntityClient查询返回的ObjectQuery对象都实现了IEnumerable接口。这样很容易将这些数据绑定到数据显示控件。更新操作可以按上文所述在相应的时间处理函数中写更新EDM的程序即可。
Entity Framework的链接字符串
默认情况下(Visual Studio对Entity Framework数据项目的默认设置)，EDM这个XML文件被作为资源在编译时嵌入到程序集中。这种情况下当更改EDM后需要重新编译这个程序集才能使更改生效。通过更改项目属性也可以让EDM作为三个独立的XML文件存在于项目中。为了让应用程序可以找到EDM（无论其以什么方式存储）需要一个链接字符串来指示EDM所在的位置。实体模型设计器生成的链接字符串如下所示：
|
<addname="ASSEntities" connectionString=" metadata=res://*/ass.csdl| res://*/ass.ssdl| res://*/ass.msl; provider=System.Data.SqlClient; provider connection string="Data Source=(local);Initial Catalog=ASS;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" /> |
http://msdn.microsoft.com/zh-cn/library/cc716756.aspx
关键的一点应用程序是怎样找到这个字符串的，对于使用EntityClient的情况，可以直接将连接字符串赋给EntityConnection的ConnectionString属性，另外对于使用ObjectContext，其可以自动由配置文件检索这个连接字符串。
（原文 ：http://www.cnblogs.com/lsxqw2004/archive/2009/05/31/1495240.html）