ADO.NET实体框架经过长时间的发展，很多用户都很了解ADO.NET实体框架了，这里我发表一下个人理解，和大家讨论讨论。实体框架是 ADO.NET 中的一组支持开发面向数据的软件应用程序的技术。面向数据的应用程序的架构师和开发人员曾为实现两个迥然不同的目标费尽心机。

他们必须为要解决的业务问题的实体、关系和逻辑构建模型，还必须处理用于存储和检索数据的数据引擎。数据可能跨多个各有不同协议的存储系统；甚至使用单个存储系统的应用程序也必须在存储系统的要求与编写高效且容易维护的应用程序代码之间取得平衡。

#T#实体框架使开发人员可以采用特定于域的对象和属性（如客户和客户地址）的形式使用数据，而不必自己考虑存储这些数据的基础数据库表和列。通过提升开发人员在处理数据时可以使用的抽象级别并减少创建和维护面向数据的应用程序所需的代码，可以实现这一目的。因为 实体框架 是 .NET Framework 的一个组件，所以 实体框架 应用程序可以在安装了 .NET Framework 3.5 Service Pack 1 (SP1) 的任何计算机上运行。

数据建模的一种由来已久且常见的设计模式是将数据模型分为三个部分：概念模型、逻辑模型和物理模型。概念模型定义要建模的系统中的实体和关系。关系数据库的逻辑模型通过外键约束将实体和关系规范化到表中。物理模型通过指定分区和索引等存储详细信息实现特定数据引擎的功能。

物理模型由数据库管理员进行优化以改善性能，而编写应用程序代码的程序员的工作主要限制为通过编写 SQL 查询和调用存储过程来处理逻辑模型。概念模型通常用作捕获和传达应用程序的要求的工具，常常以静态关系图的形式供项目早期阶段查看和讨论，随后被弃用。许多开发团队会跳过概念模型的创建，直接从指定关系数据库中的表、列和键开始工作。

ADO.NET实体框架可使开发人员查询概念模型中的实体和关系，同时依赖于 实体框架将这些操作转换为特定于数据源的命令，从而为概念模型赋予生命。这使应用程序不再对特定数据源具有硬编码的依赖性。概念模型、存储模型以及两个模型之间的映射以外部规范（称为 实体数据模型 (EDM)）表示。可以根据需要对存储模型和映射进行更改，而不需要对概念模型、数据类或应用程序代码进行更改。存储模型是特定于提供程序的，因此可以在各种数据源之间使用一致的概念模型。

EDM 由以下三种模型和具有相应文件扩展名的映射文件进行定义。
◆概念架构定义语言文件 (.csdl) -- 定义概念模型。
◆存储架构定义语言文件 (.ssdl) -- 定义存储模型（又称逻辑模型）。
◆映射规范语言文件 (.msl) -- 定义存储模型与概念模型之间的映射。

ADO.NET实体框架 使用这些基于 XML 的模型和映射文件将对概念模型中的实体和关系的创建、读取、更新和删除操作转换为数据源中的等效操作。EDM 甚至支持将概念模型中的实体映射到数据源中的存储过程。有关更多信息，请参见 实体框架中的数据建模。

面向对象的编程对与数据存储系统的交互提出了一个难题。虽然类的组织通常可比较接近地反映出关系数据库表的组织，但是拟合程度并不完美。多个规范化表通常对应于单个类，类之间的关系并未按照表之间的关系一样表示。例如，若要表示某个销售订单的客户，一个 Order 类可使用包含对 Customer 类实例的引用的属性，但是数据库中的一个 Order 表行包含的一个外键列（或列集）具有对应于 Customer 表中的主键值的值。一个 Customer 类可以具有名为 Orders 的属性，该属性包含 Order 类的实例的集合，但是数据库中的 Customer 表不包含相应的列。

现有解决方案只能通过将面向对象的类和属性映射到关系表和列来尝试弥合这种通常称为“阻抗不匹配”的差异。实体框架没有采用这种传统方法，而是将逻辑模型中的关系表、列和外键约束映射到概念模型中的实体和关系。这在定义对象和优化逻辑模型方面都增加了灵活性。实体数据模型工具基于概念模型生成可扩展数据类。这些类是分部类，可以通过开发人员添加的其他成员进行扩展。为特定概念模型生成的类派生自一些基类，这些基类提供对象服务以将实体具体化为对象以及跟踪和保存更改。开发人员可以使用这些生成的类以由导航属性关联起来的对象的形式来处理实体和关系。有关对象服务的更多信息，请参见对象服务概述（实体框架）。