提问



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


我的问题是这个。当试图决定使用Entity Framework和LINQ to SQL作为ORM时,有什么区别?


我理解它的方式,实体框架(与LINQ to Entities一起使用时)是LINQ to SQL的大哥?如果是这种情况 - 它有什么优势?它能做什么,LINQ to SQL无法独立完成?

最佳参考


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

其它参考1


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



  • LINQ to SQL是一种快速简便的方法。这意味着如果你正在做一些更小的事情,你会更快地前进,并提供更快的速度。

  • 实体框架是一种全面,无拘无束的方式。这意味着如果你正在做更大的事情,你将需要更多时间预先设定,发展得更慢,并且具有更大的灵活性。


其它参考2


LINQ to SQL真的死了吗?作者:Jonathan Allen为InfoQ.com [2]



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


其它参考3


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



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

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

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

  • EF将处理M-M关系

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



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

其它参考4


LINQ to SQL




  1. 同构数据源:SQL Server

  2. 仅适用于数据结构设计合理的小型项目

  3. 无需重新使用SqlMetal.exe
  4. 即可更改映射
  5. .dbml(数据库标记语言)

  6. 表和类之间的一对一映射

  7. 支持TPH继承

  8. 不支持复杂类型

  9. 存储优先方法

  10. 以数据库为中心的数据库视图

  11. 由C#团队创建

  12. 支持但未进一步改进



实体框架




  1. Heterogeneus数据源:支持许多数据提供者

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






另见:[3] [4]



  • LINQ to SQL Vs Entity Framework

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

  • 实体框架与LINQ TO SQL


其它参考5


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

其它参考6


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



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

  
  

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

  •   
  • 实体框架 - 如果您计划,请使用此框架
      组合视图或页面中多个表的数据。要做
      更清楚的是,上述术语是针对数据的
      在您的视图或页面中操作,而不仅仅是显示。这是
      重要的是要了解。

  •   

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

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


其它参考7


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


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

其它参考8


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


[9]


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


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

其它参考9


这里的答案涵盖了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之上支持一系列不同的应用程序。

其它参考10


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


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

其它参考11


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

其它参考12


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


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

其它参考13


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


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

其它参考14


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


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


我们正在考虑切换到Entity Framework,仅用于此功能。很遗憾微软没有实现对Linq-to-SQL的异步支持(或开源的,所以社区可以做到)。

其它参考15


LINQ to SQL和Entity Framework在表面上看起来很相似。他们都提供
LINQ使用数据模型查询数据库。


LINQ to SQL是从LINQ项目发展而来的,该项目来自团队合作
语言开发。实体框架是数据可编程性团队的一个项目,专注于实体SQL语言。微软完全无意将LINQ to SQL。


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


以下是Entity Framework(实体数据模型)执行的一些任务。


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


•完成所有数据库连接,以便开发人员不必编写大量代码与数据库进行交互。


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


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

其它参考16



  LINQ到SQL



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



  LINQ到实体



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



  根据我的个人经验,Ef更好(如果你不了解SQL)
  与用EF编写的LINQ语言相比,LINQ中的性能要快一点。