[实体框架编程] 第一章 ADO.NET实体框架简介(上)
在微软2009年11月份的专业开发者大会(PDC2009)上,那位传说中的微软卓越工程师Don Box(丹•博克斯)曾说过,“如果你是一位.NET开发人员，那么实体框架正是我们所寻找的地方。我们已到了。赶紧登船吧，是时候了。”
不错,时候到了。
开发人员耗费了大量宝贵时间考虑他们的后端数据库、表以及他们的关系、存储过程的名字和参数、视图以及他们返回的数据的模式定义。对.net开发人员来说，微软全新的实体框架改变了这种游戏规则，你书写程序时不必再关系数据存储的细节。你可以把精力全部放在程序书写的任务上而不是数据的访问。
ADO.NET实体框架已经进而转变成为构建.net应用程序的核心数据访问平台。微软在TeachEd 2006大会上宣布了实体框架，时隔2年之后，它作为Visual Studio 2008 sp1和.NET 3.5 sp1的部分一同发布.作为版本1的产品，实体框架一开始得到的是质疑，远没有大范围被采用。然而，随着2010年4月的Visual Studio 2010和.NET 4的发布，大大改进的实体框架最终赢得了关注，在广大开发人员和.NET团队中引起极大的反响，这帮家伙迅速跳上了甲板。
尽管ADO.NET保留着已有的数据访问技术，然而微软的核心数据访问技术朝着实体框架发展的战略部署将会从商业平台开发部门(拥有着微软的全部数据编程任务)吸入大量的创新和资源。对微软来说这是门很重要的技术，所以你不应当忽视。实体框架也正慢慢地被集成到了微软的众多产品中，无论是该产品使用了实体框架来支持自己的特性比如Commerce Server 2009里的多通道贸易基础，还是该产品支持与实体框架的交互比如说SQL Server建模。
然而我们为什么要一个全新的数据访问技术?在迫使了开发人员从一种数据访问技术切换到另一种的技术(从DAO到RDO,再到ADO,以及到ADO.NET的转变)之后，到了ADO.NET微软貌似已经固定下来一个开发人员可以投入的工具了。伴随每一次的Visual Studio和.NET框架的发布，ADO.NET都已经增强了并且加入了新特性，但却一直保持向后兼容性。我们的投入一直很保险。
尽管如此，但它终将停滞。实体框架是ADO.NET的另一个增强，给了开发人员除DataReaqders和DataSet以外新的访问数据和操纵结果的机制。
但是微软已经做了DataSet所力所能及的事情。下一步就应该使开发人员关注于领域模型而由.NET自动帮你做那些苦逼的数据库交互工作。
在本章你将会接触到实体框架的关键部分:实体数据模型、实体类、核心.NET API以及Visual Studio设计工具。再者，你也能了解实体框架是如何与ADO.NET的DataSet和LINQ to SQL配合工作的。最后，你还能获知很多的Visual Studio 2010和.NET 4中实体框架的改动和增加的部分，以及EF版本1中的那么多的硬伤是如何消除的。
实体关系模型：针对模型编程而不是数据库
实体框架一个主要的好处就是你不必再关注数据库的结构细节了。所有的数据访问与存储都是针对的概念模型，它反映的是你的业务对象。
在使用ADO.NET的DataReader和很多其它的数据访问技术时，你要花费大量时间用来写代码从数据库里获取数据、读取结果集并拾取你想要的数据，并把它们放入你的业务类。使用了实体框架，你不再是查询数据模式而是反映你业务模型的模式。当检索数据时，你不必被迫合理组织行与列并把它们放到对象里，因为它们返回的就是对象。当要把所做修改存回数据库时，你只需要保存这些对象就可以。实体框架做必要的工作把你的对象再转换成相关存储的行与列。实体框架所做的这些工作，正和对象关系映射(ORM)工具工作方式很相似。实体框架使用一个被称作实体数据模型(EDM)的模型，它是由实体关系建模(ERM)演化而来，ERM概念在数据库开发领域使用了很多年。
实体数据模型的根源
微软的实体框架从实体关系建模(ERM)方法演变而来,ERM已经在白板上画了有30多年了(?没大明白)。ERM定义了实体的模式以及彼此的关联。实体不同于对象，它们定义的是对象的模式而不是行为。所以说，实体有的类似于你数据库里的表模式，不同的是它描述的是业务对象的模式。开发人员绘制那么多年的ERM无非为了能够搞清如何把数据库结构化的表数据转换成程序所使用的业务对象。
说起ERM不得不提一提陈品山博士(Dr. Peter Chen),他在1976年发表的论文《The Entity-Relationship Model--Toward a Unified View of Data》被认为是第一个有关ERM的权威性著作。（http://csc.lsu.edu/news/erd.pdf）
拥有众多数据库专家的队伍的Mircosoft Research开始设计一种方法希望能够自动在概念模型与数据库模式之间架起一座桥梁。需要是一个双向通道让开发人员既能够从数据库检索数据、填充实体又可以把修改存回数据库。
2006年6月，Microsoft Research发表它的第一篇关于EDM的论文，作为对ERM的回应。这篇论文的作者包括数据库奇才Jim Gary,然而不幸的是他2007年在旧金山外海失踪。
实体数据模型:客户端的数据模型
实体数据模型(EDM)是一个客户端的数据模型,它是实体框架的核心。数据库模型隶属于数据库，这点EDM与之不同。程序中的数据模型描述的是你业务对象的结构。就好比是给了你重构企业数据库表和视图的权限，使得这些表与关系看上去更像你的业务领域而不是数据库管理人员设计的规范模式。
图1-1 规范化的数据库表模式
图1-1显示了在一个数据库中的一个典型的表集的模式。数据库管理员出于规模考虑选择了把Person放入一个单独的表中，而由PersonDetails提供了一个Person的额外信息。SalesPerson表用来提供销售人员的额外信息。
为了能访问Person记录的这些额外数据，程序里需要用到全内连接与外连接进行查询。否则就得访问一系列的预定义的存储过程与视图，每个可能需要不同的参数，并且返回值还得采用不同方式构造。
为了检索一个SalesPerson记录集以及他们各自的详细信息的T-SQL查询语句可能有点类似这样:
1 SELECT SalesPerson.*, PersonalDetails.*, Person.* 2 FROM Person 3 INNER JOIN PersonalDetails 4 ON Person.PersonID = PersonalDetails.PersonID 5 INNER JOIN SalesPerson ON Person.PersonID = SalesPerson.PersonID
设想有某个程序可能希望数据库看起来和它自己的一个视图那样。图1-2重构了该模式:
图1-2 为了匹配你的业务对象改造后的Person数据
译注:由于本人水平有限，译后未做详细的审校，希望不会对您的理解造成误解或困惑。翻译选词时有过无数拿捏不定，举例说Model-First,大白话可能就是先从模型设计开始啦，想了很久还是从“模型第一”，“模型优先”，“模型在先"...最后干脆对这种新特性术语类还是直接原文吧"Model-First"，希望不会对您造成误解与不便，如果您对译文有什么建议或意见，欢迎指正，我会在审核后重新编辑，谢谢大家!
