关于Entity Data model&掌握灵活的数据模型 EntityFramework（1）(翻译)

写在译文之前：刚走出校园才2月，一开始工作就加入到Entity data model的学习实践当中，那时还是ctp版本.什么linq to sql, linq to object更别说linq to entity了.习惯了看中文资料一下子只有很少的英文资料可看，开始一段时间真的好难适应啊.当然对于一个菜鸟而言，创建数据模型肯定不是我的职责，我只是利用查询,利用EntityDataSource对模型进行查询，当然且不讨论这种用datasource进行访问数据的好与坏.既然是beta版自然有问题，最痛苦的一周居然遇上2个bug，都是通过一点点测试，通过在forums.microsoft.com提问，和老大交流得出的结论。好不容易等到RTM版本出来，在升级的等待中，一边希望在RTM中能够修复bug，一方面祈祷不要有太大的改动。一切完毕，发现改动不是一般的大特别是EntityDataSource，修改完项目中所有的error，查看bug是否修复，还是依旧。令人失望，不得不寻找其他解决办法.不过还是有许多令人称道的地方，比如说在创建EDM模型是允许数据库的表是松散的，所有表之间的关系都可以在模型中创建，当然如果是数据库模型已经很完善了，直接可以根据数据库模型生成EDM（用 northwind就可以试试）,当然你也可以在vs中通过修改xml对模型进行修改.

以上是2个月的EDM实践的一些体会.下面是一片翻译的文章关于EDM,断断续续翻译的，文章很长，不过还是坚持了下来，很多概念不知道如何去解释就保留了英文的，觉得翻译不好的，欢迎狠狠的拍我。第一篇放在首页，后面的就放在翻译区了。

    掌握灵活的数据模型 EntityFramework  msdn杂志 7月刊

原文地址 ：http://msdn.microsoft.com/magazine/54b90ec9-3f0c-44db-ab61-dd00ba473441  

 

早在2006 ，ADO.NET Entity Framework作为ADO.NET vNext第一次被介绍，现在终于随着visual studio 2008 sp1的发布而问世。在经历了几年多次失败的尝试在相似产品上，ms伴随vs2008推出了2种技术linq to sql 和Ado.net Entity FrameWork，在某种程度上以弥补其在orm上的不足。随着新技术将不断被应用，开发人员迫切需求了解ADO.NET Entity Framework和ms下一步的走向。同时他们还想了解技术更深层次的东西，是什么让Entity Framework不同于目前流行的orm技术，以及ms推出的这一技术前景又将如何？
随着vs2008初始版本的发布侧重linq to sql，也会出现有很多的文章.这里我将关注Entity framework并提供深入的理解，在开发过程中我们应该做出怎样的选择。

Microsoft® Entity Data Model (EDM)是ADO.NET Entity Framework的真正驱动，它是基于Dr. Peter Chen's 实体关系模型（Entity Relationship (ER) model）。EDM与目前使用的orm技术相比有着更多的特性。EDM创建EF模型以提高抽象的水平，为模型的命令高于逻辑模式的同时，仍然保存的概念，实体和关系

 . 为什么需要另一个数据模型
 为什么需要另一个数据模型，随着数据公司有大量的数据增加，在理解和开发应用软件
变得非常困难，特别是在在那些最重要的数据上。数据库图表在设计的时候只是关心数据存储，比如数据完整性，性能，数据的维护性，从我个人而言，理解那些已经很不容易了
。而那些数据图表常常没有考虑到与应用程序结构统一，就更使得开发和维护更加复杂。
目前比较普遍的解决方案是开发应用程序之前，通常是把结构从其中分离出来，但不幸的是，随着自定义的解决方案数量增加，每个应用程序的数据模型需求都不相同，使得问题一直在持续。因此需要整个行业来用一种方式来接的发展应用程序域模型，可以清晰的分开逻辑模型。

 

                                           图1 Sample Entity Data Model for a Blogging Database

使用一个核心数据模型，应用程序的维护被简化了。当这一目的达到了，EDM可以定义的模型不仅仅局限于将自定义应用程序建立在ado.net实体框架上，也将投入报表和可视化应用，Intranet接口应用程序和工作流应用程序。同ER模型类似，EDM有2个重要的概念：实体(Entity)和实体之间的关系(relationships or associations)。当在理解存储实体和关系实例时，或者通过那些实例来关闭操作的集合时，集合的概念显得非常必须，因此实体（Entity）寄存在实体集（EntitySets），关系（associations）寄存在关系集（AssociationSets）。

定义在EDM中最顶层的结构概念是实体容器（Entity­Container），它定义了附近描述过的实体和关系集合的回收。这些简单的概念一起使用就可以让开发人员定义域模型，该域模型可以映射回持久层和应用程序自身的类上。在EDM中定义的每一个实体类型都能包含2种不同的成员类型，实体定义的属性（数据库中表列名）和导航属性（数据库表之间的外键）。除此之外每个实体类型必须有一个特定的身份和键值。下面的xml片断描述了bolgpost实体类型。 

Code
 1 <EntityType Name="BlogPost">
 2    <Key>
 3       <PropertyRef Name="BlogPostID" />
 4    </Key>
 5    <Property Name="BlogPostID" Type="Int32" Nullable="false" />
 6    <Property Name="BlogEntry" Type="String" Nullable="false" MaxLength="Max" 
 7              Unicode="true" FixedLength="false" />
 8    <Property Name="BlogDate" Type="DateTime" Nullable="false" />
 9    <Property Name="BlogTitle" Type="String" Nullable="false" MaxLength="500" 
10              Unicode="true" FixedLength="false" />
11    <Property Name="BlogType" Type="Int32" Nullable="false" />
12    <Property Name="CityVisited" Type="String" MaxLength="200"
13              Unicode="true" FixedLength="false" />
14    <Property Name="CountryVisited" Type="String" MaxLength="200" Unicode="true" 
15              FixedLength="false" />
16    <Property Name="DateVisited" Type="DateTime" />
17 
18    <NavigationProperty Name="Blog" Relationship=
19                        "MyTravelPostModel.FK_BlogPosts_Blogs"
20                        FromRole="BlogPosts" ToRole="Blogs" />
21    <NavigationProperty Name="Pictures" Relationship=
22                        "MyTravelPostModel.FK_Pictures_BlogPosts"
23                        FromRole="BlogPosts" ToRole="Pictures" />
24    <NavigationProperty Name="Comments" Relationship=
25                        "MyTravelPostModel.BlogComments"
26                        FromRole="BlogPosts" ToRole="Comments" />
27 </EntityType>
28 

                             图2 BlogPost Entity Type Definition

 

实体类型的属性可以是值类型和复合类型，但在Entity Framework 1.0中，属性已经不允许是实体和集合类型。实体的键值由那些属性的子集组成，导航属性定义一个实体和以另一实体的关系。  

Code
1 <ComplexType Name="Address">
 2     <Property Name="StreetAddress"
 3               Type="String" MaxLength="50" />
 4     <Property Name="Address2"
 5               Type="String" MaxLength="50" />
 6     <Property Name="City"
 7               Type="String" MaxLength="50" />
 8     <Property Name="Region"
 9               Type="String" MaxLength="50" />
10     <Property Name="PostalCode"
11               Type="String" MaxLength="50" />
12     <Property Name="Country"
13               Type="String" MaxLength="50" />
14 </ComplexType>
15 

               图3 Address Complex Type Definition

 

就像前面讨论的一样，如图3把关系作为每一个实体导航属性进行表面化,关系作为一类属性在EDM中显式的被定义。

Code
 1<Association Name="FK_Friends_People">
 2   <End Role="People" Type="MyTravelPostModel.Person" Multiplicity="1" />
 3   <End Role="Friends" Type="MyTravelPostModel.Friend" Multiplicity="*" />
 4   <ReferentialConstraint>
 5      <Principal Role="People">
 6         <PropertyRef Name="PersonID" />
 7      </Principal>
 8      <Dependent Role="Friends">
 9         <PropertyRef Name="PrimaryPersonID" />
10      </Dependent>
11   </ReferentialConstraint>
12</Association>
13

  因此简单的说，为什么我们将一个新一个创建的数据模型技术放在首位？尽管在EDM之前存在大量的数据模型技术或语言，可是没有人对他们满意，ms正在尝试着去完成。调查显示现有的大量数据模型技术，但没有能实现相当具体或专注于某些问题领域。我们开发中的EDM将创建一个模型将实现这一目的，并能真正被用来作为核心数据模型的整个一套的开发和服务器技术

Why Describe the EDM with XML?

在诸多考虑之后，xml被选作为首选的edm描述语言。Xml语言清楚地界定格式，这样无论是通过生成xml文件(资源)都可以让是开发者或第三方能够转换此格式并加载到实体框架中运行。当然也可以采用其他的语言对edm进行描述，但那些有可能替代xml的意见，在将来的产品中可能被看到。当前的edm语法被定义在xsd上，但是并不是像预期的那样，大多数开发者手动开发xml而不是使用vs里提供的工具。据说edm开发小组对特定域的语言（ dsls ）和在替代持久性机制非常感兴趣，在edm模型中那些扩展的选项正在被评估，在未来的版本中或许能看到。

掌握灵活的数据模型 EntityFramework（2）续 (翻译)

掌握灵活的数据模型 EntityFramework (3)  续 (翻译)

转载于:https://www.cnblogs.com/subway-2008/archive/2008/08/15/1268930.html