实体框架与 LINQ to SQL

现在已经发布了. NET v3.5 SP1(以及 VS2008 SP1),我们现在可以访问. NET 实体框架。

我的问题是这个。当尝试在使用实体框架和 LINQ to SQL 作为 ORM 之间做出决定时,有什么区别?

据我了解,实体框架(与 LINQ to Entities 一起使用)是 LINQ to SQL 的 “老大哥” 吗?如果是这样,它有什么优势? LINQ to SQL 不能单独做什么?

答案

LINQ to SQL 仅支持 Microsoft SQL Server 中可用的数据库表,视图,存储过程和函数的一对一映射。这是一个很棒的 API,可用于对相对设计良好的 SQL Server 数据库进行快速数据访问构建。 LINQ2SQL 最初与 C#3.0 和. Net Framework 3.5 一起发布。

LINQ to Entities(ADO.Net 实体框架)是一个 ORM(对象关系映射器)API,它允许对对象域模型及其与许多不同的 ADO.Net 数据提供者的关系进行广泛定义。这样,您可以混合并匹配许多不同的数据库供应商,应用程序服务器或协议,以设计由各种表,源,服务等构造的对象的聚合混搭。ADO.Net Framework 随. Net Framework 3.5 SP1。

这是有关 MSDN 的很好的介绍性文章:将LINQ 引入关系数据

我认为快速而肮脏的答案是

  • LINQ to SQL 是实现它的快捷方法。这意味着您将变得更快,如果您正在做较小的事情,则可以更快地交付。
  • 实体框架是一种万无一失的方法。这意味着如果您从事更大的工作,那么您将需要更多的前期时间,较慢的开发速度以及更大的灵活性。

LINQ to SQL 真的死了吗?通过乔纳森 · 艾伦为 InfoQ.com

马特 · 沃伦(Matt Warren)将 [LINQ to SQL] 描述为 “甚至都不应该存在”。本质上,它只是作为替身来帮助他们开发 LINQ,直到真正的 ORM 准备就绪为止。

...

实体框架的规模导致它错过了. NET 3.5 / Visual Studio 2008 的截止日期。它已及时完成,不幸的是命名为 “.NET 3.5 Service Pack 1”,它更像是主要版本,而不是 Service Pack。

...

由于复杂性,开发人员不喜欢 [ADO.NET 实体框架]。

...

从. NET 4.0 开始,LINQ to Entities 将成为 LINQ to Relational 方案的推荐数据访问解决方案。

@lars 发布的文章中概述了许多明显的区别,但简短的答案是:

  • L2S 紧密耦合 - 对象属性到数据库的特定字段,或更正确地将对象映射到特定的数据库模式
  • L2S 仅适用于 SQL Server(据我所知)
  • EF 允许将单个类映射到多个表
  • EF 将处理 MM 关系
  • EF 可以针对任何 ADO.NET 数据提供程序

最初的前提是 L2S 是用于快速开发,而 EF 是用于更多的 “企业” n 层应用程序,但这使 L2S 卖得短了一点。

LINQ 转 SQL

  1. 同类数据源:SQL Server
  2. 仅在数据结构设计合理的情况下才建议用于小型项目
  3. 可以更改映射而无需使用 SqlMetal.exe 重新编译
  4. .dbml(数据库标记语言)
  5. 表和类之间的一对一映射
  6. 支持TPH继承
  7. 不支持复杂类型
  8. 存储优先的方法
  9. 以数据库为中心的数据库视图
  10. 由 C#团队创建
  11. 支持但不打算进一步改进

实体框架

  1. 异构数据源: 支持许多数据提供者
  2. 建议用于所有新项目,但:
    • 小(LINQ to SQL)
    • 当数据源是平面文件(ADO.NET)时
  3. 设置模型和映射文件元数据工件过程以复制到输出目录时,可以在不重新编译的情况下更改映射
  4. .edmx(实体数据模型),其中包含:
    • SSDL(存储架构定义语言)
    • CSDL(概念架构定义语言)
    • MSL(映射规范语言)
  5. 表和类之间的一对一,一对多,多对一映射
  6. 支持继承:
    • TPH(每个层次结构表)
    • TPT(每种类型的表格)
    • TPC(每个具体类别的表)
  7. 支持复杂类型
  8. 代码优先,模型优先,存储优先的方法
  9. 以应用程序为中心的数据库视图
  10. 由 SQL Server 团队创建
  11. Microsoft Data API 的未来

也可以看看:

我在 Entity Framework 方面的经验不足。首先,您必须继承 EF 基类,因此请与 POCO 道别。您的设计必须围绕 EF。通过 LinqtoSQL,我可以使用现有的业务对象。此外,没有延迟加载,您必须自己实现。有一些解决方法可以使用 POCO 和延迟加载,但是它们存在恕我直言,因为 EF 尚未准备好。我打算在 4.0 之后再回来

我在这里找到了一个很好的答案它以简单的语言解释了何时使用:

使用哪种框架的基本经验法则是如何计划在表示层中编辑数据的计划。

  • Linq-To-Sql-如果计划在表示层中编辑数据的一对一关系,请使用此框架。这意味着您不打算在任何一个视图或页面中合并来自多个表的数据。

  • 实体框架 - 如果您计划合并视图或页面中多个表中的数据,请使用此框架。为了使这一点更清楚,上述术语是特定于将在视图或页面中操纵的数据,而不仅仅是显示的数据。了解这一点很重要。

使用 Entity Framework,您可以将表中的数据 “合并” 在一起,以可编辑的形式呈现到表示层,然后在提交该表单时,EF 将知道如何更新各个表中的所有数据。

选择 EF 而不是 L2S 可能有更准确的理由,但这可能是最容易理解的理由。 L2S 不具有合并数据以进行视图表示的功能。

我的印象是,如果 Linq2Sql 不符合您的需求,则您的数据库相当庞大或设计不当。我有大约 10 个网站,无论大小都使用 Linq2Sql。我已经看过很多次 Entity 框架,但是找不到在 Linq2Sql 上使用它的充分理由。也就是说,我尝试将数据库用作模型,因此我已经在模型和数据库之间建立了一对一的映射。

在我目前的工作中,我们有一个包含 200 多个表的数据库。一个旧的数据库,其中有很多不良的解决方案,因此我可以看到 Entity Framework 优于 Linq2Sql 的好处,但是我仍然希望重新设计数据库,因为数据库是应用程序的引擎,如果数据库设计不良且运行缓慢,则我的应用程序也会很慢。在这样的数据库上使用 Entity Framework 似乎是掩盖不良模型的快速修补程序,但它永远无法掩盖从此类数据库中获得的不良性能。

此处的答案涵盖了 Linq2Sql 和 EF 之间的许多区别,但是有一个关键点并未得到足够的重视:Linq2Sql 仅支持 SQL Server,而 EF 具有以下 RDBMS 的提供程序:

由 Microsoft 提供:

  • 用于 SQL Server,OBDC 和 OLE DB 的 ADO.NET 驱动程序

通过第三方提供商:

  • 的 MySQL
  • 甲骨文
  • DB2
  • Vista 数据库
  • SQLite 的
  • PostgreSQL 的
  • Informix
  • U2
  • Sybase 公司
  • Synergex
  • 火鸟
  • Npgsql 的

仅举几例。

这使 EF 成为关系数据存储上强大的编程抽象,这意味着开发人员可以使用一致的编程模型来使用基础数据存储。在您要开发的产品中,要确保它可以与各种常见 RDBMS 互操作的情况下,这可能非常有用。

这种抽象很有用的另一种情况是,您是与多个不同客户或组织中不同业务部门一起工作的开发团队的一员,并且您希望通过减少必须成为 RDBMS 的 RDBMS 的数量来提高开发人员的生产率。为了支持在不同 RDBMS 之上的一系列不同应用程序而熟悉。