LINQ to Entities (1)

LINQ to Entities简介

很多情况下，LINQ to SQL用来在应用程序中负责实现CRUD操作。前面也曾经分析过，直接访问数据表并不能满足程序所有的需求。因此， LINQ to SQL还允许我们调用数据库中的存储过程以及自定义函数等。不过即使这样，在某些情况下，业务模型仍旧需要更加复杂的实体结构，而不是简单的数据表与对象之间的一对一映射。

通常情况下，对于大型的数据库而言，标准化的结构能够带来更好的性能。不过标准化的数据库结构并不一定能够与业务实体对象的结构保持一致。在这种情况下，我们可以使用数据库中的视图来抹平二者之间的不同。图8-9就给出了一个这样的实例。其中添加了一个新的数据表，用来存储地址信息。这样，数据库中任何地址相关的数据均可存放在该表中。图8-9中就演示了将Author和Publisher中的地址信息存放在Address表中的方法。

图8-9　为Author和Publisher表添加公用的Address表

注意     这里的目的仅仅是作为演示，而并不意味着图8-9中的表结构已经达到了最优。在数据库标准化的过程中，我们需要根据实际需要进行不同的处理。

在上述示例中，我们希望通过标准化将地址信息拆分到单独的一个数据表中。不过，业务实体中却希望能够将作者、用户以及地址信息统统组合到单一的对象中，这样才能更加自然地表示一个作者。若需要的仅仅是按照这样的形式查看数据，那么只需在数据库中添加一个视图即可实现，这样也将数据表的关联操作与实际业务需求彻底隔离开来。

不过问题在于，这种使用视图的方法并不能完成对数据的更新操作。1976年，Peter Chen博士在一篇有创意的论文中提出了一种实体-关系模型。在这篇论文中，Peter Chen博士指出我们可以通过在物理模型（数据库）和逻辑模型（对象）之间插入一个概念模型来实现二者的分离。

在某种意义上，这个概念模型有些类似于数据库中的视图——将来自不同数据源中的数据组合起来。不过，该概念模型还提供了更多视图无法支持的功能。首先，与视图不同的是，实体数据模型（Entity Data Model，EDM）提供了数据来源的所有信息，这就为更新数据打下了坚实的基础。这类元数据提供了每个值的实际存储位置，这样即可容易地实现更新操作。此外，EDM还提供了同时存放对象和关系的能力，以便在概念模型中创建完全动态的对象层次结构。

在开发LINQ查询语言的同时，微软公司的数据团队也在实现这种概念模型，以便能够更好地处理此类复杂的实体结构。这个技术被叫做ADO.NET Entity Framework（EF），它能够通过一系列的XML映射文件将物理模型和逻辑模型分离开来。如图8-10所示。

图8-10　Entity Framework的各层

在EF中，数据库表被一对一地映射到逻辑层的实体中。逻辑层实体是通过基于XML的存储架构定义语言（Store Schema Definition Language，SSDL）文件来定义的。其映射文件的结构与LINQ to SQL的映射文件非常类似。

EF比LINQ to SQL多走的一步就是它接下来使用了另一个基于XML的映射文件（Mapping Schema Language，MSL）将逻辑模型与概念模型映射了起来。概念模型是通过同样基于XML的概念架构定义语言（Conceptual Schema Definition Language，CSDL）文件来定义的。如果需要的话，这些概念模型能够进一步被转化成强类型的对象。

建立好EDM关系之后，程序即可使用一种基于字符串的、名为Entity SQL的语言对EDM进行查询。我们也能够使用LINQ to Entities将LINQ的相关知识应用到EDM之上。因为EDM已经将应用程序与数据库完全分离开来，所以对数据库的修改并不需要重新编译应用程序，而只需修改EDM映射文件即可。

这种结构提高了物理层和逻辑层之间的分离程度，进而允许我们在修改数据模型以及映射结构时无需对应用程序进行改动。此外，因为EF建立于现有的ADO模型之上，所以该框架也能够很容易地与其他的非SQL Server数据库配合使用。因此，若你需要在其他数据库上使用LINQ，那么就可以使用LINQ to Entities和EF作为数据访问层的实现。