实体框架与LINQ to SQL

827

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

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

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

.net entity-framework linq-to-sql

138

我认为应该重新检查以下答案，因为自EF发布以来已有很长的时间，所以来到这里的新开发人员可能会产生错误的印象。自从早期发布以来，EF便成为了一种出色且便捷的工具。您只需要建立与数据库的连接，就可以完成90％的连接。从经验的角度看发展非常迅速！从那里-LINQ是您最好的朋友。它是高度可定制的，MVC只是喜欢它，并且对那些说它很糟糕的人也很喜欢-学习如何首先使用它（并牢牢掌握LINQ）！

— graumanoz

10

显而易见，MSFT有效地杀死了LINQ2SQL以支持EF。但是，MSFT开源EF的事实帮助它减少了吸吮，并且肯定会越来越好。但是对于进入EF的任何人-请务必了解EF中仍然存在很多怪癖。我已经张贴了关于一个- stackoverflow.com/questions/305092/...

— nikib3ro

4

@ kape123，（a）LINQ to SQL不是“死”的；它仍然可以使用；（b）LINQ to SQL是Windows Phone 8开发中的标准数据访问方法。

— Ryan Lundy 2014年

9

@ user3308043，[需要引用]。

— Ryan Lundy 2014年

3

@Kyralessa-截至2010年（随着最新发现的.NET4.0版本，我可以找到），MS承认，尽管可能会在LINQ2SQL上进行一些投资，但“我们的整体投资中的大部分将来自实体框架。”

— kmote 2015年

483

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引入关系数据

— 克里斯
source

看起来您使用LINQ to SQL在EF中进行查询

— PositiveGuy 2010年

11

@CoffeeAddict虽然它们使用LINQ lambda的样式非常相似，但每个API都有完全不同的基础。例如，LINQ2SQL生成SQL查询的方式允许使用SQL函数，而L2E则没有，或者至少从2008

— Kris

2

EF面向对象的方法使它真正易于使用，可以非常快速地进行编码，管理。对我来说，这是访问数据的最佳方法。

— Antoine Pelletier，2015年

10

这个答案已经过时了。现在，Linq to SQL支持one2many映射

— George Lanetz

201

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

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

— 布拉德·图特罗
source

32

您还倾向于使用L2S编写更少的代码行来完成与EF相同的事情。EF中不会延迟加载，这意味着您始终在检查是否已加载某些内容。

— Paul Mendoza，

布拉德，您对电子商务网站有何建议？我的意思是，除了简单的CRUD之外，我什么都看不到...

— PositiveGuy 2010年

2

@CoffeeAddict显然，在投票最多的答案中前3名表示L2S用于简单的CRUD

— IsmailS 2010年

11

@Banford在.NET 4.0中使用EF时，我认为它比L2S更好。L2S在3.5中的EF中缺少的功能已添加到.NET 4.0中的EF中。现在，.NET 4.0中的EF中的LINQ语句看起来与L2S中的几乎相同。在L2S提供的功能之外，EF还为您提供了一些您现在可以做的额外事情。

— 保罗·门多萨

40

这个答案现在已有5年历史了，已经过时了。Entity Framework 6现在处于Beta中，并且进行了很大的改进，包括延迟加载，枚举支持等

— Tim

109

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方案的推荐数据访问解决方案。

— 扎克·彼得森
source

56

实际上，我们不喜欢EF，因为EF的设计师如此差劲，而且越野车极为极端。我从未发现它是如此复杂。

— BlueRaja-Danny Pflughoeft，2010年

12

很多主要的电子商务站点都使用LINQ to SQL。例如：红盒子，＃2，等等

— PositiveGuy

14

我知道很多使用LINQ to SQL的优秀开发人员，并说这些文章完全被夸大了。我同意。LINQ to SQL已在功能强大的.coms中使用，现在仍在使用。

— PositiveGuy 2010年

4

是的，在L2EF查询的整数属性上调用.ToString（）不会引起异常。

— StingyJack 2011年

3

@ BlueRaja-DannyPflughoeft超过5年后它仍然正确吗？

— 维卡斯·拉纳

94

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

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

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

— 詹姆斯·苏格鲁
source

13

您的报价“ L2S仅适用于SQL Server（据我所知）”需要更新：开源项目“ dblinq”将LINQ to SQL程序集替换为可以与MySQL，PostgreSQL，Ingres，Firebird，SQLite对话的程序集。 ..和Microsoft SQL（当然）。

— 康坦戈

1

等待...所以EF不会创建紧密耦合的DL对象？

— PositiveGuy 2010年

7

是的，L2S并非企业级解决方案的原始前提已不再成立。我的意思是StackOverflow可在L2S和一堆其他.com（例如Redbox）上运行，等等。

— PositiveGuy 2010年

74

LINQ转SQL

同类数据源：SQL Server
仅在数据结构设计合理的情况下才推荐用于小型项目
可以更改映射而无需使用SqlMetal.exe重新编译
.dbml（数据库标记语言）
表和类之间的一对一映射
支持TPH继承
不支持复杂类型
存储优先的方法
以数据库为中心的数据库视图
由C＃团队创建
支持但不打算进一步改进

实体框架

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

也可以看看：

— 里扎德·迪甘
source

6

这是最新和最详细的答案。

— ErTR

2

例如，当您在编写时，实体框架是否不使用 LINQ to SQL dbSet<Orders>.Where()...ToList()？我认为，从LINQ到SQL反对使用Entity Framework是一种误导。

— Don Cheadle

4

@mmcrae EF不使用 L2S，它们都是底层数据库的linq提供者。如果将其解释为Linq-to-a-database，类似于linq-to-objects和linq-to-xml，那么是的，两者在linq-to-adatabase中都是相似的。但是不，EF不使用L2S（反之亦然）。两个完全分开的工具。

— 马滕

4

“ 不同意所有其他项目的建议。” Code First是快速运行小型项目的捷径。除此之外，对该问题进行了重大更新。

— DrewJordan

51

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

— 智代
source

7

缺少POCO支持是我一直在实体框架上选择LINQ to SQL的第一原因。正如他们希望的那样，我可能会在下一个版本中将EF合并时重新考虑EF。还有一些其他项目可以为EF执行POCO，但还不够干净。

— 约瑟夫·弗里斯

27

如果有人（例如我）不知道POCO代表什么：普通的旧CLR对象

— CBono

4

我真的不明白不支持POCO的大惊小怪是什么……这是抽象专家的另一层。创建一个工厂，注入数据存储库并在那里构建您的POCO。无论如何这可能是个好主意。

— 八十一联合

3

我听说在EF 4

— PositiveGuy 2010年

8

POCO支持现在已经可用，继承不再是实体类的要求@CoffeeAddict POCO只是一个简单的对象，不依赖于特定的框架，并且是现代实体框架模式的重要组成部分

— Chris McGrath，2012年

46

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

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

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

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

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

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

— 纳瓦兹
source

36

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

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

— 萜烯基
source

1

您遗漏了一点-即使是小型数据库，您可能想要的东西与数据库表和代码/域对象之间的1：1关系不同。只取决于您要在总线/域对象中进行多少抽象。

— 炼金术

18

我意识到：)今天，我想对我的业务实体进行手工编码。我仍然使用Linq2sql，但仅在我的存储库中使用Linq2sql获取数据并将linq2sql实体转换为自定义业务实体。也许比使用or-mapper还要多一些工作，但是我仍然希望使我的业务层不受任何OR-mapper特定代码的影响。

— terjetyl 2010年

25

您可以在这里找到一个很好的比较：

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

— Omer K
source

2

答案中的某些内容不正确。如果您使用Code First，则不需要EDMX。而且我不明白当您使用Code First时DI如何发挥作用。

— 马滕

1

同样，Linq to SQL可以从模型类中填充数据库。不知道它是否也可以生成数据库本身，但是生成模式和表是否属于SQL的Linq功能。

— 汤姆·林特

感谢您的回答，我认为一个人可以使用sqlmetal.exe docs.microsoft.com/zh-cn/dotnet/framework/tools/…从数据库中生成代码/映射Linq to SQL

— Vinod Srivastav

23

此处的答案涵盖了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之上的一系列不同应用程序而熟悉。

— 风帆
source

15

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

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

— 班福德
source

12

如果您的数据库简单明了，则LINQ to SQL可以。如果您需要在表顶部放置逻辑/抽象的实体，请使用Entity Framework。

— 文塔纳
source

4

实体框架允许数据库顶部的抽象层。今天，许多OR映射器的问题（以我的观点）是，它们在表和类之间提供了一对一的映射。数据库模型并不总是反映出我们对业务模型的思考方式。

— senfo

跑出空间。无论如何，基于以上所述，我认为您的答案并不完整。

— senfo

7

我认为这确实是个坏建议。无论数据库的简单性或复杂性如何，L2S都很好。真正的陷阱没有适当分离关注点。如果您尝试合并业务层和数据访问层，并对所有内容使用Linqed up对象，则将发现L2S限制。但这是过于简单和整体设计的问题。L2S是一个很好的DAL，如果您将查询和持久性视为与业务规则分开的关注点，从长远来看，您将在很多领域避免很多麻烦。

— mattmc3

1

这告诉我什么。用你的话来说简单吗？

— PositiveGuy 2010年

1

举例来说，您需要“逻辑/抽象”的意思。是的，我知道抽象是什么，但是请根据您的情况举个例子。向我确切地解释您在说什么。这些话，所以我不知道你是什么意思。

— PositiveGuy 2010年

8

两者均不支持唯一的SQL 2008数据类型。从我的角度来看，不同之处在于，在某些将来的版本中，Entity仍然有机会围绕我的地理数据类型构建模型，而Linq to SQL被遗弃，永远不会。

想知道nHibernate或OpenAccess是怎么回事...

— 约翰·邓纳根
source

3

从Entity Framework 5开始支持SQL Server 2008空间数据类型（Open Geospatial Consortium OGS）。还支持其他提供程序（Devart for Oracle）。请参阅msdn.microsoft.com/en-us/data/dn194325。

— subsci 2013年

6

我认为，如果您需要快速开发某些东西而中间没有任何奇怪的东西，并且您需要该工具具有代表表的实体：

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

— MRFerocius
source

4

“中间没有奇怪的事情”，好的，这是什么意思。“中间发生奇怪的事情”的示例

— PositiveGuy 2010年

编辑或删除此答案将是很好的选择，它对于现代开发不再有用，并且可能使人们误入歧途。

— 朱利奥·卡钦

6

我正在为拥有使用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。

还需要考虑其他一些选项，例如LLBLGen。它是一种成熟的ORM解决方案，已经存在了很长时间，并且已被证明比MS数据解决方案（ODBC，ADO，ADO.NET，Linq-2-SQL，EF，EF.core）更具前瞻性。

— 拉蒙·德克莱因
source

2

Linq到SQL

它是提供程序，仅支持SQL Server。这是一种将SQL Server数据库表映射到.NET对象的映射技术。这是Microsoft首次尝试使用ORM-对象关系映射器。

LINQ到实体

是相同的想法，但是在后台使用实体框架，就像ORM一样（来自Microsoft），它支持多个数据库实体框架的主要优点是开发人员可以在任何数据库上工作，而无需学习语法来对不同的不同数据库执行任何操作

根据我的个人经验，与以lambda编写的EF原因LINQ语言相比，Ef在LINQ中的性能更好（如果您不了解SQL）。

— 乌曼·帕特瓦（Umang Patwa）
source