.NET 4.0实体框架和LINQ to SQL之间有什么区别？

What is the difference between Entity Framework and LINQ to SQL by .NET 4.0?

我正在检查专业版ASP.NET MVC的第二版，并实现了ef替换linq到sql。我对第一本书中的linq-to-sql很熟悉，但我对ef一无所知。不管怎样，在阅读代码时，除了名称似乎什么都没有改变。相同的旧存储库类，相同的旧函数。

我做了一点调查。我知道Linq不局限于SQL。此外，EF也不受Microsoft系列SQL服务器的限制。在这个2岁的问题中，人们对英孚不满意，说它太复杂了。但现在我读的是同一个代码。只有通过向SQL中插入LINQ的ADO.NET实体模型生成类。既然英孚现在是事实上的标准ORM，有人能消除人们对英孚功能的担忧吗？

它们有些相似，可以以非常相似的方式使用，代码方面，但是它们有一些重要的区别。注意，"linq"与"linq to sql"不同；ef也使用linq。一些显著的区别是：

LINQtoSQL主要是仅用于SQL Server的，而不是设计上的，而是实现上的。如果您有一个兼容的ADO.NET提供程序，那么EF将支持并支持多个DBS。
开箱即用，LinqtoSQL对于数据库元数据的更改来说有一个非常糟糕的情况。您必须从头开始重新生成模型的某些部分，并且会丢失自定义设置。
EF支持多对多关系和继承等模型功能。linq to sql不直接支持这些。
在.NET3.5中，LinqtoSQL对特定于SQL服务器的功能的支持比EF要好得多。在.NET 4中，这一点基本上不正确；它们在这方面相当相似。
EF允许您选择ModelFirst、DB First或Code First建模。现成的linq to sql实际上只支持db-first。

英孚的年龄是4.0。在那之前，用起来有点疼，我不推荐。现在我的建议是，所有新的linq-to-db代码都使用ef4。

就新特性而言，LINQ部分实际上与LINQtoSQL非常相似。但它是一个完全不同的体系结构：EF4充当(EF)ADO.NET提供程序的LINQ提供程序，而后该提供程序包装另一个ADO.NET提供程序。所以有一些新的东西，比如实体SQL(我不使用)和EF支持不同的底层ADO.NET提供程序(我确实使用)。

EF使用的XML建模系统也允许更强大的映射抽象。我经常使用的一种方法是使用具有相同主键的不同表映射到实体继承关系；据我所知，在Linq to SQL中执行此操作的唯一方法是通过"选择器列"(尽管我从未在Linq to SQL中尝试过)。

相关讨论

Linq to SQL和实体框架之间的区别：

LINQ to SQL：

它只适用于SQL Server数据库。
它生成一个.dbml来保持关系
它不支持复杂类型。
它无法从模型生成数据库。
它只允许在实体类和关系表/视图之间进行一对一的映射。
它允许您使用DataContext查询数据。
它提供了一种紧密耦合的方法。
它只能与SQL Server一起用于快速应用程序开发。

实体框架

它可以用于各种数据库，如Oracle、DB2、MySQL、SQL Server等。
它最初生成一个.edmx文件。使用3个不同的文件.csdl、.msl和.ssdl维护关系。
它支持复杂类型。
它可以从模型生成数据库。
它允许实体类和关系表/视图之间的一对一、一对多和多对多映射。
它允许您使用EntitySQL、ObjectContext和DbContext查询数据。
它提供了一种松散耦合的方法。因为它的代码优先方法允许您使用依赖注入模式，这使得它松散耦合。
它可以用于使用RDBMS快速开发应用程序，如SQL Server、Oracle、DB2和MySQL等。

更多细节

最新的ef更加健壮，并且您不会被强迫进入由设计师驱动的伪ORM体验(或者如果您试图在没有设计师的情况下进行配置的话，也不会陷入配置的泥沼)。你的模型现在可以是poco对象，而不是一些由设计师驱动的部分类损坏的b，这些b与设计师驱动的代码内在地耦合在一起，你可以完全离开设计师，而不会感觉你在逆流而上，一般来说，感觉他们只是听了社区的话，或者实际上试图模仿现有的bat。TLE测试了解决方案，而不是为"morts"或L2SQL设计一个版本。