如果您的数据库简单明了，LINQ to SQL就可以了。如果您需要在表上添加逻辑/抽象实体，请使用实体框架。

解决并发冲突

同质数据源：SQL Server仅适用于数据结构设计良好的小型项目可以在不使用SqlMetal.exe重新编译的情况下更改映射.dbml（数据库标记语言）表和类之间的一对一映射支持TPH继承不支持复杂类型存储优先方法以数据库为中心的数据库视图由C#团队创建支持但不打算进一步改进

实体框架

异构数据源：支持多个数据提供者建议用于所有新项目，以下项目除外：小型（LINQ to SQL）当数据源是平面文件（ADO.NET）时在将模型和映射文件元数据工件过程设置为复制到输出目录时，可以在不重新编译的情况下更改映射.edmx（实体数据模型），包含：SSDL（存储架构定义语言）概念模式定义语言映射规范语言表和类之间的一对一、一对多、多对一映射支持继承：TPH（每个层次的表）TPT（每种类型的表格）TPC（混凝土等级表）支持复杂类型代码优先、模型优先、存储优先的方法以应用程序为中心的数据库视图由SQL Server团队创建Microsoft Data API的未来

另请参见：

LINQ To SQL与实体框架LINQ to SQL与实体框架的区别实体框架与LINQ TO SQL

如果您的数据库简单明了，LINQ to SQL就可以了。如果您需要在表上添加逻辑/抽象实体，请使用实体框架。

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

我的印象是，如果Linq2Sql不符合您的需求，那么您的数据库就相当糟糕或者设计得非常糟糕。我有大约10个大大小小的网站都在使用Linq2Sql。我已经多次查看和实体框架，但我找不到在Linq2Sql上使用它的好理由。也就是说，我尝试使用我的数据库作为模型，所以我已经在模型和数据库之间建立了1对1的映射。

在我目前的工作中，我们有一个拥有200多个表的数据库。一个有很多糟糕解决方案的旧数据库，因此我可以看到实体框架优于Linq2Sql的好处，但我还是希望重新设计数据库，因为数据库是应用程序的引擎，如果数据库设计糟糕且速度慢，那么我的应用程序也会很慢。在这样的数据库上使用Entity框架似乎是一种快速修复方法，可以掩盖坏模型，但它永远无法掩盖从这样的数据库中获得的糟糕性能。

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

使用哪个框架的基本经验法则是如何规划在演示层中编辑数据。Linq To Sql-如果您计划编辑一对一的表示层中数据的关系。意思是你不要计划在任何一个视图中组合来自多个表的数据或第页。实体框架-如果您计划在视图或页面中组合来自多个表的数据。制作更清楚的是，上述术语是特定于在视图或页面中操纵，而不仅仅是显示。这是重要的是要理解。使用实体框架，您可以将表格数据“合并”在一起以可编辑的形式呈现给演示层，然后提交表格后，EF将知道如何更新所有数据从各种表格中选择。可能有更准确的理由选择EF而不是L2S，但是这可能是最容易理解的。L2S没有能够合并数据以进行视图显示。