《Entity Framework 6 Recipes》翻译系列 (1) -----第一章 开始使用实体框架之历史和框架简述

　　微软的Entity Framework 受到越来越多人的关注和使用，Entity Framework7.0版本也即将发行。虽然已经开源，可遗憾的是，国内没有关于它的书籍，更不用说好书了，可能是因为EF版本更新太快，没人愿意去花时间翻译国外关于EF的书籍。使用Entity Framework开发已经有3年多了，但用得很肤浅，最近想深入学习，只好找来英文书《Entity Framework 6 Recipes》第二版，慢慢啃。首先需要说明的是，我英文不好，只是为了学习EF。把学习的过程写成博客，一是督促自己，二是希望能帮助有需要的朋友。EF是微软极力推荐的新一代数据库访问技术，它已经成熟，做为一名.NET开发人员，如果你还没有使用它的话，那感紧开始吧，特别是DDD（领域驱动设计）的爱好者，更应该学习它，因为它是领域模型的绝佳搭档！另外，本书也是一本关于EF的佳作（其实，英文的关于EF的书也就那么几本，中文的目前还没有，只有一些零星的资料，这会让初学者会感觉到混乱，特别是什么EDMX文件、Code First、Model First、Database First、表拆分，实体拆分，TPT,TPH,TPC，CodeFirst和DDD的配合等等），就从本系列开始对EF进行一个系统的学习吧，老鸟也可以从中了解不少的知识点。文中肯定有很多翻译不当的地方，恳请你指正，以免误导大家。谢谢！由于书中的代码只贴出核心部分，如果你想运行示例代码，可以加入QQ群下载，因为太大，超过博客园的限制，所以这里提供不了下载。要说的就这么多，下面就开始这一段学习过程吧。

第一章 开始使用实体框架

　　处理关系数据库时,我们依据由行和列组成的表，它高度结构化且擅长处理记录集。在面向对象编程被广泛接受之前,我们使用“procedurally（过程化）”的思维并通过编写结构化的、自上而下的、一个一个的函数来解决问题。它们完美对应：在代码中，表、行、列和结构化、过程化模式完美匹配。这样的情况，持续了很长一段时间。

　　在编码方面，我们现在使用面向对象和领域模型，架构、设计和编码都对应于现实世界中的事情,比如客户和订单。我们在白板上写出问题域（problem space)中的名词，通过绘制它们之间的连线来表示关联和交互。并以此作为规范和给开发团队分配工作的依据。总之，架构、设计、和编码是基于概念层，已经和关系型数据库的组织和逻辑有很大的差别。

　　软件开发中分析和解决问题的方法已经进化成熟，然而关系型数据库却没有。很多年来，数据依然是保持在表、行、列这样模式里。不幸的是，它在面向对象继承和高度标准化的关系型数据库中产生了一个失配（阻抗失配，微软的安德斯.海尔斯伯格<C#之父>可能会这样叫它）。

　　为了应对这一差距，项目中经常引入“数据库层（database layer）”来转换应用程序领域实体类中数据到表中的行和列进行保存。由此产生了许多商业和开发的数据库访问框架。他们都希望在进化式的开发和结构化数据中架起一座桥。有趣的是，一个新的解决方案-对象关系映射（ORM）产生了。

　　实体框架，以及集成查询语言（LINQ)框架，他们均出自微软，使我们能处理抗阻失配问题。使用实体框架，我们能在设计器或是代码中直接对领域实体类进行建模。还能建立实体类之间的关系。面对这些实体类以及他们之间的关系我们构建LINQ查询来应对，LINQ允许我们在代码中使用实体类以及他们之间的关系来表达关系型数据库中的概念。这些在帮助我们减少开发工作量的同时，还有助于简化我们的开发体验。相对大量、高度冗余代码的ADO.NET数据访问方式，我们使用LINQ查询来表达我们对数据的需求。使用面向实体对象编程方式代替面向高度结构化的关系型数据库开发方式，实体框架会帮你实现实体类到底层数据库的映射。

注意：我们使用的术语实体类或实体对象，是一个代表应用程序中领域项的一个类。领域类代表现实世界中的对象，例如，你的项目中表示员工，部门，经理的类。 应用程序的最终用户能够在应用程序中看到领域类并说，“是的，这就是我们业务所做的”。实体类定义概要或者属性，没有行为，本质上，实体类暴露对象的状态。

1-1实体框架简述

　　实体框架是微软提供的实现应用程序访问数据的战略解决方案，不同以往的技术。实体框架与Visual Studio一起提供一个综合的，基于模型的生态系统，它能让你开发广泛的面向数据的应用程序，包含桌面应用，互联网应用，云应用，以及基于服务的应用。本书将覆盖绝大多数主题。

历史

实体框架不是一个新事物，它可追溯到Visual Studio 2008 ，在功能和特性上它经历一段漫长历程。如图1-1：

图1-1 实体框架的简短历史

 　　实体框架的第一个版本，提供了有限的功能，它只提供了ORM最基本的特性，只实现了一种叫做“数据库优先（Database First）的方案，本书将对此方案进行充分展示。版本4.0带来一种叫做“模型优先（Model First）“的方案，对简单公共语言运行时对象（Plain Old CLR Object(POCO))的完整支持，以及默认的数据延迟加载行为。不久之后，实体框架的开发团队发布了三个小的版本-4.1到4.3，提供了另一种叫做“代码优先（Code First）”的方案。如上图所示，版本5.0随.NET Framework4.5和Visual Studio2012一起发布。提供了重大的性能改进，并支持了枚举类型，表值函数，空间数据类型，存储过程的一系列改进，以及对asp.net MVC框架的深度支持。

　　现在实体框架已经到了版本6.0，提供了查询和更新的异步支持，在代码优先（Code First）中，存储过程支持更新，性能改进，以及一系列的新特性，本书将聚焦这些新特性。

注意：实体框架版本5.0同样也能在Visual Studio 2010中使用，版本6.0随Visual Studio 2013一起发布，已提供对Visual Studio 2012 和Visual Studio 2010运行时支持。

　　对于分层集(level set），我们简短地查看一下实体框架系统的关键组件。但绝不意味着是一个综合的描述，它将用几百页的篇幅。我们通过查看一些关键点帮助你了解本书的核心。

模型

　　实体框架是一个强烈关注建模的技术，当你使用实体框架建模时，你会看到很多从之前的技术和模式继承下来的似曾相识的符号。比如，一个相似的实体关系图和广泛采用的概念、逻辑、及物理分层方法。

　　实体框架创建的模型是一个名叫实体数据模型（EDM）的模型，它允许你在编码时使用强类型的实体类，不是关系型数据库中的结构和对象。（图1-2展示了在概念层的模型），实体数据模型允许你自定义实体类和关系型数据库表之间的映射，不仅仅是经典的一对一或类到表的映射。

图1-2 实体数据模型

 　　在图1-2中，展示了左边的数据库表不直接映射到右边的实体类型（代码中使用）的。实体数据模型中的映射能力使开发者可以使用与问题域（problem domain）高度一至的实体类型集，替代高度结构化的数据库。以设计出高性能、可伸缩、可维护的代码。

　　例如，上面图中标注的，Employees,Devices,以及Phone Numbers 在物理存储中是使用的三张不同的表。从DBA（数据库管理员）的观点来看，这是一个完美的场景。但是，从开发人员，或项目相关相关人员的角度来看，employee是一个单一的包含Devices和phone numbers的对象，开发人员编码时使用一个单一的Employee实体类，它包含Devices和Phone Numbers的集合。开发人员不知道也不关心数据库管理员是如何把这个对象分别存储在三张不同的数据库表中的。一旦配置，单一对象和三张数据库之间的映射将被实体框架处理。

　　一个相反的情形是，上图中的单表Department被映射成三个代表特定的departments。同样的，开发人员和项目相关人员用一个单独的对象来表示每一个部门（Accounting,Marketing,Finance,等等）,但DBA出于对数据在存储的优化，将这三个对象整合到一个单一的数据库表中。

　　当然，你能看到上图中的Location表，你能很容易的将它映射到单一的实体类，也这是实体框架的默认行为。

　　这里的关键点在，开发人员和项目相关人员使用表示应用程序上下文中的领域实体类，而DBA构建底层的数据库表以求创建高效和数据库。实体框架能很容易地架起两者单的桥梁。

分层

　　实体数据模型包含3个独立的层，概念层、存储层、映射层。每个层互不耦合。

　　实体类包含在实体数据模型的概念层中，这一层为开发人员和项目相关人员所使用。根据你如何使用实体框架，概念层能通过设计器和代码来建模。一旦做出决定，你可以使用逆向工程从一个已有的数据库中建模，或借助设计器和大量的工具能通过代码建模，以及使用实体框架来生成数据库。概念层的语法是通过概念架构定义语言（CSDL）来定义的。

　　任何有用的应用程序都需要将对象持久化到某一数据存储系统中，实体框架中的数据模型定义表、列，关系以及映射到底层数据库中的数据类型。存储架构定义语言（SSDL）定义了存储模型的语法。

　　最后，映射层定义概念层和存储层的之间的映射。除此之外，该层定义实体类的属性如何映射到数据库表中的列。它在实体数据模型的映射详细信息窗口、数据注解、以及基于代码方式的API向开发人员呈现。它的语法由映射规格语言（MSL)来定义。

术语

　　实体框架有自己的词汇表，如果你已经使用别的流行的ORM工具或者与之相似的数据库模型，也许，在这之前你已经遇到一些词汇。虽然完整的词汇表的数量是巨大的，但我们只提供少数基本术语便让我们开始学习。

　　如前所述，一个实体类型代表领域模型中的一个类。一个实体类型的实例通常是指一个实体。如果你使用实体框架设计器，一个实体类型在设计器中被表示成一个拥有不同属性的方框。图1-3展示两个实体类型：Employee和Task.

图1-3 Employee和Task一对多关系的模型

 　　一个实体类型一般拥有一个或多个属性。像一个类，一个属性是一个特定数据类型的指定值。 属性可以是像 integer,string等简单类型；也可以是复合类型（ComplexTypes）；或者是一个集合。导航属性（Navigation properties）是指跟其它实体有关联的属性（数据库中的外键关系）。在实体类型中不是导航属性的属性通常叫做标量属性（scalar proerties）.

　　两个实体之间的关系(relationship)叫做关联(association). 实体类型间的关联在设计器中表示为连接两者的一条直线。线的两端带有表示多重性的注解。图1-3中的关联是一个表示Employeet和Task之间一对多的关联。一个Employee可以有0个或是多个Tasks。每个Task关联一个确定的Employee。

　　每个实体类型都有一个属性或一个属性集来指示它的实体键。在实体框架中一个实体键唯一标识一个实体，一般它被映射到实体对应的底层数据库表的主键。

　　最后，没有讨论实体框架而不提到上下文对象（context object)的。上下文对象是实体框架服务的入口，它暴露实体对象，管理数据库连接，生成参数化的SQL语句，从数据库中封送（marshals）数据或封送数据到数据库，缓存对象，维护对象变化跟踪，把无类型的结果集转换到一个强类型的集合对象。

　　一开始，上下文对象为ObjectContext对象，现在，实体框架支持另一个最新的名为DbContext的上下文对象。DbContext大大简单化了使用实体框架的体验。有趣的是，DbContext是ObjectContext的一个包装器或者外观实现者。以一种直观的、友好的、有效的方式暴露底层ObjectContext的功能。

　　无疑，DbContext已经是使用实体框架的首选。同时本书也将非常详细地介绍它。

代码

 　　尽管有可视化的设计器的强有力支持，实体框架到处是代码，模型、实体类型、关联、映射等最终的具体的代码来表述，这些代码最终成为应用程序的一部分。他们可以由Visual Studio和实体框架产生，也可由开发团队手工创建。你可以选择一些代码生成工具来生成，或者通过修改你项目中不同的属性，或者修改底层的代码生成模板来生成。

 　　Visual Studio 使用一个名为T4(Text Template Transformation Toolkit)模板的代码生成技术来自动生成代码。Visual Studio中的T4模板支持你编辑出能生成适合你确切需要的代码的模板。虽然这是一项高级技术，但我们在很多情况下都需要使用它。我们将会向你展示如何修改它的一些方法。

　　作为一种选择，你可以利用最新的代码优先（Code-First）技术来手工创建具体的代码，以此控制整个过程。使用代码优先，开发人员可以在没有设计器的帮助下创建实体类，映射，上下文对象。手工创建的实体类，一般是指简单公共语言运行时对象（POCO-Plain Old CLR Objects），它没有依赖实体框架设施。更有趣的是，开发团队可以利用实体框架的强大的实用工具（可以从微软官方网站下载）从一个存在的数据库中逆向生成代码优先模型。第八章将向你展示使用POCO创建之前的创建实体类、映射、上下文对象工作的基本过程。贯穿本书的大量方法将向你展示如何使用 Code-First 解决N-层架构的应用程序。

 

第一篇就暂时学到这里吧，欲知详情，请见下回分解。 如果你觉对你有帮助，请点右下解的推荐以示支持。谢谢。转载请注明出处：http://www.cnblogs.com/VolcanoCloud/p/4475119.html

 

实体框架交流QQ群:  458326058，欢迎有兴趣的朋友加入一起交流

谢谢大家的持续关注，我的博客地址：http://www.cnblogs.com/VolcanoCloud/