实体框架与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中可用的数据库表，视图，sprocs和函数的1对1映射。 这是一个很好的API用于快速的数据访问建设相对精心设计的SQL Server数据库。 LINQ2SQL最初是用C＃3.0和.Net Framework 3.5发布的。
LINQ to Entities（ADO.Net实体框架）是一个ORM（对象关系映射器）API，它允许广泛定义对象域模型及其与许多不同的ADO.Net数据提供者的关系。 因此，您可以混合和匹配多个不同的数据库供应商，应用程序服务器或协议，以设计从各种表，源，服务等构建的对象的聚合mash-up。ADO.Net Framework随.Net Framework 3.5 SP1。
这是关于MSDN的一篇很好的介绍性文章：将LINQ引入关系数据
我认为快速和肮脏的答案是
- LINQ to SQL是快速简单的方法。 这意味着如果你正在做一些更小的事情，你会更快，更快。
- 实体框架是全方位的，没有任何阻碍的方式来做到这一点。 这意味着如果你正在做更大的事情，你会花更多的时间在前面，慢慢地发展，并且有更多的灵活性。
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 to关系场景的推荐数据访问解决方案。
这篇文章里面列出了一些明显的区别，但简短的回答是：
- L2S紧密耦合 – 对象属性到特定的数据库字段或更正确地将对象映射到特定的数据库模式
- L2S将只能与SQL Server一起工作（据我所知）
- EF允许将单个类映射到多个表
- EF将处理MM关系
- EF将能够定位任何ADO.NET数据提供者
最初的前提是L2S适用于快速开发，而EF则适用于更多的“企业级”n层应用，但是这样卖L2S的时间有点短。
我对实体框架的经验一直不及。 首先，您必须从EF基础类继承，所以请告诉POCO。 你的设计必须在EF左右。 有了LinqtoSQL，我可以使用现有的业务对象。 另外，没有延迟加载，你必须自己实现。 有一些工作在那里使用POCOs和延迟加载，但他们存在恕我直言，因为EF还没有准备好。 我计划在4.0之后回来
我在这里找到了一个非常好的答案，解释了何时用简单的话来说：
使用哪个框架的基本经验法则是如何计划编辑表示层中的数据。
Linq-To-Sql – 如果您计划在表示层中编辑数据的一对一关系，请使用此框架。 这意味着您不打算在任何一个视图或页面中合并来自多个表格的数据。
实体框架 – 如果您计划组合来自视图或页面中多个表的数据，请使用此框架。 为了更清楚地说明，上面的术语是特定于将在您的视图或页面中操纵的数据，而不仅仅是显示的。 这是重要的理解。
使用实体框架，您可以将表格数据“合并”在一起，以可编辑的形式呈现到表示层，然后当提交表单时，EF将知道如何更新来自各个表的所有数据。
选择EF over L2S可能有更准确的原因，但这可能是最容易理解的。 L2S不具备合并数据进行视图展示的功能。
LINQ to SQL
- 同类数据源：SQL Server
- 建议仅适用于数据结构设计良好的小型项目
- 无需使用SqlMetal.exe重新编译即可更改映射
- .dbml（数据库标记语言）
- 表和类之间的一对一映射
- 支持TPH继承
- 不支持复杂类型
- 存储优先的方法
- 以数据库为中心的数据库视图
- 由C＃团队创建
- 支持，但不打算进一步改进
实体框架
- 异种数据源： 支持许多数据提供者
- 推荐用于所有新项目，除了：
- 小的（LINQ to SQL）
- 当数据源是平面文件（ADO.NET）
- 在设置模型和映射文件时，可以更改映射，而无需重新编译将元数据工件过程复制到输出目录
- .edmx（实体数据模型）包含：
- SSDL（存储模式定义语言）
- CSDL（概念模式定义语言）
- MSL（映射规范语言）
- 表和类之间的一对一，一对多，多对一的映射
- 支持继承：
- TPH（表每个层次）
- TPT（每种类型的表格）
- TPC（每个具体类的表）
- 支持复杂的类型
- 代码优先，模型优先，存储优先的方法
- 以应用程序为中心的数据库视图
- 由SQL Server团队创建
- 微软数据API的未来
也可以看看：
- LINQ到SQL Vs实体框架
- LINQ to SQL和实体框架的区别
- 实体框架与LINQ TO SQL
我的印象是，如果Linq2Sql不适合你的需求，你的数据库是非常enumous或非常糟糕的设计。 我有大约10个网站，都是使用Linq2Sql的大小。 我已经看了很多次实体框架，但我找不到通过Linq2Sql使用它的一个很好的理由。 这就是说我尝试使用我的数据库作为模型，所以我已经在模型和数据库之间有1对1的映射。
在我目前的工作中，我们有一个有200多个表格的数据库。 一个旧的数据库有很多不好的解决方案，所以我可以看到实体框架优于Linq2Sql的好处，但我仍然希望重新设计数据库，因为数据库是应用程序的引擎，如果数据库设计得不好，速度慢，那么我的应用程序也会变慢。 在这样的数据库上使用Entity框架看起来像是一个quickfix来掩饰不好的模型，但它永远不会掩盖从这样的数据库中获得的糟糕的性能。
这里的答案已经涵盖了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之上的一系列不同的应用程序。
我发现在使用EF时我不能在同一个数据库模型中使用多个数据库。 但是在linq2sql中，我可以通过在数据库名称前加上模式名称。
这是我最初开始使用linq2sql的原因之一。 我不知道EF是否已经允许这个功能，但是我记得读过它的意图是不允许这样做。
如果你的数据库简单直接，LINQ to SQL就可以做到。 如果你需要逻辑/抽象的实体顶部的表，然后去实体框架。
既不支持独特的SQL 2008数据类型。 与我的观点不同的是，Entity在将来的版本中仍然有机会围绕我的地理数据类型构建一个模型，并且Linq to SQL将会被抛弃。
不知道nHibernate或OpenAccess有什么问题
我认为如果你需要快速开发一些东西，而不需要中间的东西，那么你需要设施来代表你的表格：
Linq2Sql可以是一个很好的联盟，与LinQ一起使用，释放了一个很大的发展时机。
LINQ to SQL和实体框架在表面上看起来类似。 他们都使用数据模型提供对数据库的LINQ查询。
LINQ to SQL是从LINQ项目演化而来的，这个项目是由语言开发团队提出的。而实体框架是数据可编程团队的一个项目，专注于实体SQL语言。 微软一直没有打算将LINQ to SQL进行分解。
LINQ to SQL仍然是ADO.NET的一部分，而Entity框架有单独的API。 实体框架是LINQ to SQL的更高版本。实体框架使用实体数据模型来桥接应用程序和数据存储。 实体数据模型（EDM）提供了您的概念模式的定义，以及与数据库交互所需的数据库模式信息，以及最后一个链接到两个的映射模式。
以下是由Entity Framework（实体数据模型）执行的一些任务。
•自动生成模型中的类，并在模型更改时动态更新这些类。
•关注所有的数据库连接，以便开发人员不必为编写数据库而编写大量代码。
•提供查询模型的常用查询语法，而不是查询数据库，然后将这些查询转换为数据库可以理解的查询。
•提供一种机制，用于在应用程序中使用模型对象时跟踪对模型对象所做的更改，并处理对数据库的更新。
LINQ到SQL
它是仅支持SQL Server的提供者。 这是将SQL Server数据库表映射到.NET对象的映射技术。 微软是第一次尝试ORM – 对象关系映射器。
LINQ到实体
是一样的想法，但在后台使用实体框架，作为ORM – 再次从微软，它支持多个数据库主要优势的实体框架是开发人员可以在任何数据库上工作，无需学习语法，以在不同的不同的数据库上执行任何操作
根据我个人的经验，Ef比LINF更好（如果你对SQL不了解），那么与LINQ语言编写的lambda相比，LINQ的性能要快一些。
我正在为有一个使用Linq-to-SQL的大项目的客户工作。 当项目开始的时候，这是明显的选择，因为Entity Framework当时缺乏一些主要特性，Linq-to-SQL的性能非常糟糕。
现在，EF已经发展，Linq-to-SQL缺乏用于高度可伸缩服务的主要特性，并且支持异步操作。 我们有时每秒有超过100个请求，尽管我们已经优化了我们的数据库，但大多数查询仍然需要几毫秒才能完成。 由于同步数据库调用，线程被阻塞，不能用于其他请求。
我们正在考虑切换到实体框架，仅用于此功能。 微软并没有在Linq-to-SQL中实现异步支持（或开放源代码，所以社区可以这么做），这真是一个耻辱。
