我正在为一个使用Linq to SQL的大型项目的客户工作。当项目开始时，这是一个明显的选择，因为当时实体框架缺乏一些主要功能，Linq to SQL的性能要好得多。

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

我们正考虑切换到实体框架，仅用于此功能。遗憾的是，微软没有在Linq to SQL中实现异步支持（或者开源，所以社区可以这样做）。

2018年12月补遗：微软正在向.NET Core迁移，而Linq-2-SQL在.NET Core上不受支持，因此您需要迁移到EF，以确保将来可以迁移到EF.Core。

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

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

不知道nHibernate或OpenAccess有什么问题。。。

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

LINQ to SQL是实现这一目标的快速简便的方法。这意味着如果你正在做一些小的事情，你会更快地完成任务，更快地交付。实体框架是一种全面、无限制的方法。这意味着如果你在做更大的事情，你会提前花更多的时间，发展得更慢，并且有更大的灵活性。

在@lars发布的文章中，有许多明显的区别，但简短的回答是：

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

最初的前提是L2S用于快速开发，EF用于更多的“企业级”n层应用程序，但这使L2S的销售有点不足。

LINQ to SQL真的死了吗？Jonathan Allen为InfoQ.com撰写

马特·沃伦（Matt Warren）将[LINQ to SQL]描述为“根本就不应该存在”的东西。从本质上讲，在真正的ORM准备就绪之前，它只是应该帮助他们开发LINQ。...实体框架的规模导致它错过了.NET 3.5/VVisual Studio 2008的最后期限。它及时完成了不幸命名为“.NET 3.5 Service Pack 1”，它更像是一个主要版本，而不是一个Service Pack。...由于复杂性，开发人员不喜欢[ADO.NET实体框架]。...从.NET 4.0开始，LINQ to Entities将是LINQ to关系场景的推荐数据访问解决方案。

我发现在使用EF时，我不能在同一个数据库模型中使用多个数据库。但在linq2sql中，我只需在模式名称前面加上数据库名称即可。

这是我最初开始使用linq2sql的原因之一。我不知道EF是否已经允许这一功能，但我记得读到它的初衷是不允许这一点。