实体框架与 LINQ to SQL

StackOverflow https://stackoverflow.com/questions/8676

题

现在 .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 中可用的数据库表、视图、存储过程和函数的 1 对 1 映射。它是一个很棒的 AP​​I，可用于对设计相对良好的 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 的 Jonathan Allen

马特·沃伦（Matt Warren）将[linq to sql]描述为“甚至不应该存在”的东西。本质上，应该替身来帮助他们发展Linq，直到真正的ORM准备就绪。

...

实体框架的规模导致它错过了 .NET 3.5/Visual Studio 2008 的最后期限。它及时完成了不幸的命名为“.NET 3.5 Service Pack 1”，它更像是一个主要版本而不是服务包。

...

由于复杂性，开发人员不喜欢[ADO.NET Entity Framework]。

...

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

@lars 发布的那篇文章中概述了许多明显的差异，但简短的答案是：

  • L2S 是紧密耦合的——对象属性到数据库的特定字段，或者更准确地说，对象映射到特定的数据库模式
  • L2S 只能与 SQL Server 一起使用（据我所知）
  • EF允许将单个类映射到多个表
  • EF 将处理 M-M 关系
  • EF 将能够定位任何 ADO.NET 数据提供程序

最初的前提是L2S是为了快速开发，而EF是为了更“企业”的n层应用程序，但是卖L2S有点短。

LINQ 到 SQL

  1. 同质数据源：SQL服务器
  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 数据 API 的未来

也可以看看：

我在实体框架方面的经验并不是很出色。首先，您必须继承 EF 基类，所以要告别 POCO。您的设计必须围绕 EF。借助 LinqtoSQL，我可以使用现有的业务对象。此外，没有延迟加载，您必须自己实现。有一些解决方法可以使用 POCO 和延迟加载，但恕我直言，它们存在是因为 EF 尚未准备好。我打算4.0之后再回来

我找到了一个很好的答案 这里 用简单的话解释了何时使用what：

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

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

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

使用实体框架，您可以将数据合并在一起，以以可编辑的形式将其呈现给演示层，然后在提交该表单时，EF将知道如何更新各种表中的所有数据。

可能有更准确的理由选择EF优于L2，但这可能是最容易理解的。L2S没有合并数据以进行查看表示的能力。

我的印象是，如果 Linq2Sql 不能满足您的需求，那么您的数据库将非常庞大或设计得很糟糕。我有大约 10 个大大小小的网站都使用 Linq2Sql。我已经多次查看实体框架，但找不到在 Linq2Sql 上使用它的充分理由。也就是说，我尝试使用数据库作为模型，因此模型和数据库之间已经有了 1 对 1 的映射。

在我目前的工作中，我们有一个包含 200 多个表的数据库。一个旧数据库有很多糟糕的解决方案，所以我可以看到实体框架相对于 Linq2Sql 的好处，但我仍然更愿意重新设计数据库，因为数据库是应用程序的引擎，如果数据库设计得很糟糕并且速度很慢，那么我的应用程序也会很慢。在此类数据库上使用实体框架似乎是掩盖不良模型的快速修复方法，但它永远无法掩盖从此类数据库获得的不良性能。

这里的答案已经涵盖了 Linq2Sql 和 EF 之间的许多差异，但有一个关键点没有得到太多关注：Linq2Sql 仅支持 SQL Server，而 EF 具有以下 RDBMS 的提供程序：

微软提供：

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

通过第三方提供商：

  • MySQL
  • 甲骨文
  • 数据库2
  • 维斯塔数据库
  • SQLite
  • PostgreSQL
  • 信息系统
  • U2
  • 赛贝斯
  • 协同
  • 火鸟
  • NpgSQL

仅举几例。

这使得 EF 成为关系数据存储之上的强大编程抽象，这意味着无论底层数据存储如何，开发人员都可以使用一致的编程模型。当您正在开发一个产品并希望确保与各种常见的 RDBMS 进行互操作时，这可能非常有用。

这种抽象有用的另一种情况是，您是一个开发团队的一员，该团队与许多不同的客户或组织内的不同业务部门合作，并且您希望通过减少他们必须成为的 RDBMS 的数量来提高开发人员的生产力熟悉以支持不同 RDBMS 之上的一系列不同应用程序。

我发现使用EF时无法在同一个数据库模型中使用多个数据库。但在 linq2sql 中，我可以通过在模式名称前加上数据库名称作为前缀。

这是我最初开始使用 linq2sql 的原因之一。我不知道 EF 是否已允许此功能，但我记得读过它的目的是不允许此功能。

如果您的数据库简单明了，那么 LINQ to SQL 就可以了。如果您需要在表顶部添加逻辑/抽象实体，那么请选择实体框架。

两者都不支持独特的 SQL 2008 数据类型。从我的角度来看，不同之处在于 Entity 仍然有机会在未来的某个版本中围绕我的地理数据类型构建模型，而 Linq to SQL 已被放弃，永远不会。

想知道 nHibernate 或 OpenAccess 怎么样......

我认为如果您需要快速开发一些中间没有奇怪的东西的东西，并且您需要具有代表您的表的实体的设施：

Linq2Sql 可以成为一个很好的盟友，将它与 LinQ 一起使用可以释放一个很好的开发时机。

我正在为有一个使用 Linq-to-SQL 的大型项目的客户工作。当项目开始时，这是显而易见的选择，因为当时 Entity Framework 缺乏一些主要功能，而 Linq-to-SQL 的性能要好得多。

现在 EF 已经发展，Linq-to-SQL 缺乏异步支持，这对于高度可扩展的服务来说非常有用。有时我们每秒有 100 多个请求，尽管我们已经优化了数据库，但大多数查询仍然需要几毫秒才能完成。由于同步数据库调用，线程被阻塞，无法用于其他请求。

我们正在考虑切换到实体框架，只是为了这个功能。遗憾的是，Microsoft 没有在 Linq-to-SQL 中实现异步支持（或者将其开源，以便社区可以做到）。

2018 年 12 月附录： Microsoft 正在转向 .NET Core，而 .NET Core 不支持 Linq-2-SQL，因此您需要迁移到 EF 以确保将来可以迁移到 EF.Core。

还有一些其他选项需要考虑，例如 LLBL基因. 。它是一个成熟的 ORM 解决方案，已经存在很长时间了，并且已被证明比 MS 数据解决方案（ODBC、ADO、ADO.NET、Linq-2-SQL、EF、EF.core）更具面向未来的能力。

LINQ to SQL 和实体框架表面上看起来很相似。他们都使用数据模型针对数据库提供LINQ查询。

Linq到SQL从LINQ项目演变，该项目来自与语言开发合作的团队。虽然实体框架是数据可编程性团队的一个项目，并且专注于实体SQL语言。Microsoft 确实无意贬低 LINQ to SQL。

LINQ to SQL 仍然是 ADO.NET 的一部分，而实体框架有单独的 API。实体框架是 LINQ to SQL 的更高版本。实体框架使用实体数据模型来桥接应用程序和数据存储。实体数据模型（EDM）提供了概念模式的定义以及与数据库交互所需的数据库模式信息，最后提供了链接到两者的映射模式。

以下是实体框架（实体数据模型）执行的一些任务。

•自动从模型中生成类，并在模型更改时动态更新这些类。

• 负责所有数据库连接，以便开发人员不必编写大量与数据库交互的代码。

• 提供用于查询模型而不是数据库的通用查询语法，然后将这些查询转换为数据库可以理解的查询。

•提供了一种在应用程序中使用并处理数据库的更新时，可以跟踪对模型对象的更改的机制。

Linq 到 SQL

它是仅支持 SQL Server 的提供商。它是一种将 SQL Server 数据库表映射到 .NET 对象的映射技术。是 Microsoft 对 ORM（对象关系映射器）的首次尝试。

实体连接

是相同的想法，但是在后台使用实体框架，作为 ORM - 再次来自微软，它支持多个数据库实体框架的主要优点是开发人员可以在任何数据库上工作，无需学习语法即可在不同的不同数据库上执行任何操作

根据我的个人经验，LINQ中的EF（如果您不了解SQL）更好的速度比Lambda编写的LINQ语言要快一些。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top