04 第四讲 ADONET实体框架.doc

第四讲 ADO.NET实体框架 长久以来，程序员和数据库总是保持着一种微妙的关系，在商用应用程序中，数据库一定是不可或缺的元件，这让程序员一定要为了连接与访问数据库而去学习 SQL 语句，然而在众多设计工具中，数据以对象的形式体现。因此在业界中有很多人都在研究如何将对象模型和数据库集成在一起，对象关系对应 (Object-Relational Mapping) 的技术就是由此而生，像Hibernate或NHibernate都是这个技术下的产物，而微软虽然有了ADO.NET这 个数据访问的利器，但却没有像NHibernate这样的对象对应工具，因此微软在.NET Framework 2.0发展时期，就提出了一个ObjectSpace的概念，ObjectSpace可以让应用程序可以用完全对象化的方法连接与访问数据库，其技术概念 与NHibernate相当类似，然而ObjectSpace工程相当大，在.NET Framework 2.0完成时仍无法全部完成，因此微软将ObjectSpace纳入下一版本的.NET Framework中，并且再加上一个设计的工具(Designer)，构成了现在的 ADO.NET Entity Framework。 Entity Framework 利用了抽象化数据结构的方式，将每个数据库对象都转换成应用程序对象 (entity)，而数据字段都转换为属性 (property)，关系则转换为结合属性 (association)，让数据库的 E/R 模型完全的转成对象模型，如此让程序设计师能用最熟悉的编程语言来调用访问。而在抽象化的结构之下，则是高度集成与对应结构的概念层、对应层和储存层，以 及支持 Entity Framework 的数据提供者 (provider)，让数据访问的工作得以顺利与完整的进行。 4.1 为概念模型赋予生命数据建模的一种由来已久且常见的设计模式是将数据模型分为三个部分：概念模型、逻辑模型和物理模型。概念模型定义要建模的系统中的实体和关系。关系数据库的逻辑模型通过外键约束将实体和关系规范化到表中。物理模型通过指定分区和索引等存储详细信息实现特定数据引擎的功能。 物理模型由数据库管理员进行优化以改善性能，而编写应用程序代码的程序员的工作主要限制为通过编写 SQL 查询和调用存储过程来处理逻辑模型。概念模型通常用作捕获和传达应用程序的要求的工具，常常以静态关系图的形式供项目早期阶段查看和讨论，随后被弃用。许多开发团队会跳过概念模型的创建，直接从指定关系数据库中的表、列和键开始工作。 实体框架可使开发人员查询概念模型中的实体和关系，同时依赖于实体框架 将这些操作转换为特定于数据源的命令，从而为概念模型赋予生命。这使应用程序不再对特定数据源具有硬编码的依赖性。概念模型、存储模型以及两个模型之间的映射以外部规范（称为 实体数据模型 (EDM)）表示。可以根据需要对存储模型和映射进行更改，而不需要对概念模型、数据类或应用程序代码进行更改。存储模型是特定于提供程序的，因此可以在各种数据源之间使用一致的概念模型。 EDM 由以下三种模型和具有相应文件扩展名的映射文件进行定义。 概念架构定义语言文件 (.csdl) -- 定义概念模型。 存储架构定义语言文件 (.ssdl) -- 定义存储模型（又称逻辑模型）。 映射规范语言文件 (.msl) -- 定义存储模型与概念模型之间的映射。 实体框架 使用这些基于 XML 的模型和映射文件将对概念模型中的实体和关系的创建、读取、更新和删除操作转换为数据源中的等效操作。EDM 甚至支持将概念模型中的实体映射到数据源中的存储过程。 将对象映射到数据面向对象的编程对与数据存储系统的交互提出了一个难题。虽然类的组织通常可比较接近地反映出关系数据库表的组织，但是拟合程度并不完美。多个规范化表通常对应于单个类，类之间的关系并未按照表之间的关系一样表示。例如，若要表示某个销售订单的客户，一个 Order 类可使用包含对 Customer 类实例的引用的属性，但是数据库中的一个 Order 表行包含的一个外键列（或列集）具有对应于 Customer 表中的主键值的值。一个 Customer 类可以具有名为 Orders 的属性，该属性包含 Order 类的实例的集合，但是数据库中的 Customer 表不包含相应的列。 现有解决方案只能通过将面向对象的类和属性映射到关系表和列来尝试弥合这种通常称为“阻抗不匹配”的差异。实体框架 没有采用这种传统方法，而是将逻辑模型中的关系表、列和外键约束映射到概念模型中的实体和关系。这在定义对象和优化逻辑模型方面都增加了灵活性。实体数据模型 工具基于概念模型生成可扩展数据类。这些类是分部类，可以通过开发人员添加的其他成员进行扩展。为特定概