实体框架与LINQ to SQL

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

我的问题是这个.在尝试使用Entity Framework和LINQ to SQL作为ORM时,有什么区别？

我理解它的方式,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的"大哥"？如果是这种情况 - 它有什么优势？它能做什么LINQ to SQL本身无法做到的？

1> Kris..：

---

LINQ to SQL仅支持Microsoft SQL Server中可用的数据库表,视图,Sproc和函数的1对1映射.这是一个很好的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到关系数据

---

@CoffeeAddict使用LINQ lambdas时它们的风格非常相似,每个API都有完全不同的基础.例如,LINQ2SQL生成SQL查询的方式允许使用SQL函数,而L2E则没有,或者至少在2008年没有.

---

This answer is obsolete. Now Linq to SQL supports one2many mapping

---

EF面向对象的方法使其使用起来非常简单和方便,可以非常快速地进行编码和管理.对我来说,只是获取数据的最佳方式.

2> Brad Tuttero..：

---

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

LINQ to SQL是一种快速简便的方法.这意味着如果你正在做一些更小的事情,你会更快,更快地交付.

实体框架是一种全面,无拘无束的方式.这意味着如果你正在做更大的事情,你会花更多时间在前面,发展得更慢,并且具有更大的灵活性.

---

这个答案现在已经有5年了,而且已经过时了.实体框架6现在处于测试阶段并得到很大改进,包括延迟加载,枚举支持等.

---

你也倾向于使用L2S编写更少的代码行来完成与EF相同的操作.EF中没有延迟加载意味着您​​始终在检查是否已加载某些内容.

---

@Banford在.NET 4.0中使用EF我认为它比L2S更好.在3.5中EF中缺少的功能已经将L2S添加到.NET 4.0中的EF中.现在,在.NET 4.0中的EF中的LINQ语句看起来与L2S中的语句几乎相同.EF为您提供了一些额外的东西,您可以在L2S提供的基础上做些什么.

---

@CoffeeAddict显然,最受欢迎的答案中排名前三的是简单CRUD的L2S

3> Zack Peterso..：

---

LINQ to SQL真的死了吗？作者:Jonathan Allen来自InfoQ.com

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到关系场景的推荐数据访问解决方案.

---

实际上,我们不喜欢EF,因为它有如此糟糕的设计师而且非常极端,*极其错误.我从来没有发现它是那么复杂.

---

我知道有很多优秀的开发人员使用LINQ to SQL,并说这些文章完全被夸大了.我同意.LINQ to SQL已经在强大的.com中使用,现在仍然如此.

---

很多主要的电子商务网站都使用LINQ to SQL.示例:Redbox,Stackoverflow等

---

是的,在L2EF查询中的整数属性上调用.ToString()不应该导致异常.

---

@ BlueRaja-DannyPflughoeft超过5年后仍然如此吗？

---

恕我直言,如果你依赖于设计师那么你正在为自己设置问题我以后只使用设计师进行快速设置并在我习惯使用设计师之后维护代码但总是遇到限制并且已经转向更好诸如使用代码第一个框架将现有数据库映射到代码并使用ef电动工具进行快速设置之类的事情

4> JamesSugrue..：

---

@lars上发表的文章中列出了许多明显的差异,但简短的回答是:

L2S紧密耦合 - 对象属性与数据库的特定字段或更正确的对象映射到特定的数据库模式

L2S只适用于SQL Server(据我所知)

EF允许将单个类映射到多个表

EF将处理MM关系

EF将能够定位任何ADO.NET数据提供程序

最初的前提是L2S用于快速开发,而EF用于更多"企业级"n层应用程序,但这就是销售L2S有点短.

---

您的引用"L2S仅适用于SQL Server(据我所知)"需要更新:开源项目"dblinq"将LINQ to SQL程序集替换为可与MySQL,PostgreSQL,Ingres,Firebird,SQLite交谈的程序集. ..和Microsoft SQL(当然).

---

是的,L2S不是企业级解决方案的原始前提不再是真实的.我的意思是StackOverflow运行在L2S和一些其他.com(如Redbox)等等.

5> Ryszard Dżeg..：

---

LINQ to 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的未来

---

也可以看看:

LINQ to SQL Vs实体框架

LINQ to SQL与实体框架之间的区别

实体框架与LINQ TO SQL

---

这是最新,最详尽的答案.

---

@mmcrae EF不使用*L2S,它们都是底层数据库的linq提供者.如果你把它解释为Linq-to-a-database,类似于linq-to-objects和linq-to-xml,那么是的,两者在linq-to-a-database中都是相似的.但不,EF不使用L2S(反之亦然).两个完全分开的工具.

---

"推荐用于所有新项目,除了......小型项目"**我不同意.**Code First是一个非常快速的方式来实现小型项目.除此之外,这个问题的重大更新.

6> Jiyosub..：

---

我对实体框架的体验并不那么出色.首先,你必须继承EF基类,所以要对POCO说再见.您的设计必须围绕EF.使用LinqtoSQL,我可以使用现有的业务对象.此外,没有延迟加载,您必须自己实现.有一些工作要使用POCO和延迟加载,但它们存在恕我直言,因为EF尚未准备好.我计划在4.0之后再回来

---

如果某人(像我一样)不知道POCO代表什么:[Plain Old CLR Object](http://en.wikipedia.org/wiki/Plain_Old_CLR_Object"Wikipedia - Plain Old CLR Object")

---

POCO支持现在可用,继承不再是实体类的要求@CoffeeAddict POCO只是一个简单的对象,不依赖于特定的框架,是现代实体框架模式的主要部分

---

缺乏POCO支持是我在实体框架上选择LINQ to SQL的首要原因.我们可能会重新考虑EF,因为他们将其纳入下一版本,正如他们所承诺的那样.还有一些额外的项目为EF做POCO,但还不够干净.

---

我真的不明白不支持POCO的大惊小怪......它是一个更多层次的抽象人.创建一个工厂,注入数据存储库并在那里构建您的POCO.无论如何,这可能是一个好主意.

---

我听说EF 4可以使用POCO

7> Nawaz..：

---

我在这里找到了一个非常好的答案,它解释了何时使用简单的单词:

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

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

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

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

选择EF而不是L2S可能有更准确的理由,但这可能是最容易理解的.L2S无法合并数据以进行视图呈现.

8> terjetyl..：

---

我的印象是,如果Linq2Sql不符合您的需求,您的数据库非常有用或设计得非常糟糕.我使用Linq2Sql大约有10个网站,无论大小.我已经看了很多次实体框架,但我找不到在Linq2Sql上使用它的一个很好的理由.也就是说我尝试将我的数据库用作模型,因此我已经在模型和数据库之间进行了1对1的映射.

在我目前的工作中,我们有一个包含200多个表的数据库.一个包含大量不良解决方案的旧数据库,因此我可以看到实体框架优于Linq2Sql,但我仍然希望重新设计数据库,因为数据库是应用程序的引擎,如果数据库设计错误,那么我的应用程序速度慢也会很慢.在这样的数据库上使用Entity框架似乎是一个快速修复来掩盖坏模型,但它永远不会掩盖从这样的数据库中获得的糟糕性能.

---

我已经意识到:)今天我喜欢手工编码我的业务实体.我仍然使用Linq2sql,但只在我的存储库中,我使用Linq2sql获取数据并将linq2sql实体转换为我的自定义业务实体.也许比使用or-mapper更多的工作,但我仍然希望我的业务层不受任何OR-mapper特定代码的影响.

9> Omer K..：

---

你可以在这里找到一个很好的比较:

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

10> saille..：

---

这里的答案涵盖了Linq2Sql和EF之间的许多差异,但是有一个关键点没有得到太多关注:Linq2Sql只支持SQL Server,而EF有以下RDBMS的提供者:

由Microsoft提供:

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

通过第三方提供商:

MySQL的

神谕

DB2

VistaDB的

SQLite的

PostgreSQL的

Informix的

U2

SYBASE

Synergex公司

火鸟

Npgsql的

仅举几例.

这使得EF成为关系数据存储的强大编程抽象,这意味着无论底层数据存储如何,开发人员都可以使用一致的编程模型.在您开发要确保与各种常见RDBMS互操作的产品的情况下,这可能非常有用.

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

11> Banford..：

---

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

这是我最初开始使用linq2sql的原因之一.我不知道EF是否已经允许这个功能,但我记得读过它的意图是不允许这样做.

12> vintana..：

---

如果您的数据库简单明了,LINQ to SQL就可以了.如果您需要在表顶部使用逻辑/抽象实体,那么请转到Entity Framework.

---

我认为这是非常糟糕的建议.无论数据库的简单性或复杂性如何,L2S都是好的*.真正的陷阱没有适当的关注点分离.如果您尝试合并业务层和数据访问层,并将Linqed up对象用于所有内容,那么您将找到L2S限制.但这是一个过于简单和单一设计的问题.L2S是一个很棒的DAL,如果你认为查询和持久性是你的业务规则的一个单独的问题,从长远来看,你将在很多方面省去很多麻烦.

---

实体框架允许对数据库顶部进行抽象层.今天许多OR Mappers的问题(在我看来)是它们在表和类之间提供了1对1的映射.数据库模型并不总是反映出我们根据业务模型对其进行思考的方式.

13> John Dunagan..：

---

它们都不支持唯一的SQL 2008数据类型.与我的观点不同的是,Entity仍然有机会在未来的某个版本中围绕我的地理数据类型构建模型,Linq to SQL被抛弃,永远不会.

想知道nHibernate或OpenAccess的用途......

---

从Entity Framework 5开始支持SQL Server 2008 Spatial数据类型(Open Geospatial Consortium OGS).其他提供程序(Devart for Oracle)也受支持.请参阅http://msdn.microsoft.com/en-us/data/dn194325.

14> MRFerocius..：

---

我想如果你需要快速开发一些东西,而中间没有奇怪的东西,你需要设施来代表你的表:

Linq2Sql可以是一个很好的联盟,使用它与LinQ释放出一个很好的开发时机.

---

"中间没有奇怪的东西",好吧,你的意思是什么."中间奇怪的事"的例子

15> Ramon de Kle..：

---

我正在为有一个使用Linq-to-SQL的大项目的客户工作.当项目启动时,它是显而易见的选择,因为当时实体框架缺少一些主要功能,Linq-to-SQL的性能要好得多.

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

我们正在考虑切换到实体框架,仅用于此功能.遗憾的是,微软并没有在Linq-to-SQL中实现异步支持(或者是开源的,所以社区可以做到这一点).

附录2018年12月: Microsoft正在向.NET Core发展,Linq-2-SQL不支持.NET Core,因此您需要迁移到EF以确保将来可以迁移到EF.Core.

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