那么现在对这两种产品的判断是什么？对于VS2010 / .net 4.0
，我似乎无法找到关于此问题的任何内容回到.net 3.5天，大多数人认为当.net 4.0出现时，Linq2SQL将会死机，但它似乎还活着。
另一方面，EF 4.0似乎已经有了显着的改善。
对我来说，到目前为止，我的大部分工作都是中小型项目，我的公司很快就会从VS08迁移到VS10。我应该看什么？或者真的，我应该花时间研究EF4.0还是花时间更好地研究nHibernate？ （但回到主题，我对Linq2Sql - EF真的更感兴趣。）
最后，我目前正在使用entlib / unity，哪个框架对依赖/策略注入更友好？
提前致谢。
答案 0 :(得分：24)
以下是Entity Framework（v4）更好的原因：
1 - L2SQL本质上是过时的
2 - L2SQL不支持POCO映射，EF确实如此。
3 - EF具有更大的灵活性（代码优先，模型优先，数据库优先）。 L2SQL只有1个。
4 - EF支持SPROC - ＆gt; POCO映射
5 - EF具有Entity-SQL，允许您在需要时返回到经典的ADO.NET
6 - EF支持继承（TPT，TPH）
7 - EF与Repository模式密切相关，并通过IQueryable延迟执行
8 - EF组件（ObjectSet，ObjectContext）很容易模拟并允许DI
我想不出为什么新项目应该使用L2SQL。
有些人可能会说“L2SQL适用于小型项目，我可以拖放并完成它”。
你也可以用EF4做到这一点，如果你决定修改/扩展你的项目，你将在长期内获得更多的灵活性/支持。所以这不是借口。
HTH
答案 1 :(得分：16)
只是添加到之前的答案和评论（这三个人都获得了+1票）：
a）性能：L2S运行时比EF更轻量级（由于只有一个层; EF必须处理两个模型层及它们之间的映射）。
EF通常会生成比L2S更冗长的TSQL，但大多数时候只会影响可读性，如果您正在分析并查看生成的查询; SQL优化器最终将使用相同的执行计划大多数。但是，在某些情况下，查询会变得如此庞大和复杂，以至于可能会对性能产生影响。
L2S在进行客户端查询优化方面也略胜一筹;它消除了可以在客户端评估的where子句谓词，因此数据库不必担心它们。这意味着SQL Server优化器的工作量减少，并且您最终会遇到“糟糕”的执行计划的风险会降低。
b） L2S与L2E ：在将使用普通CLR方法的LINQ查询转换为TSQL时，L2S仍然略好于L2E，尤其是涉及DateTime及其相关方法时。 L2E支持或多或少相同的东西，但是通过它自己的EntityFunctions类：http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx。
在我看来，L2S和EF都是很好的选择，选择一个你觉得舒服的东西，并涵盖你现在需要的东西以及你正在编写的代码的合理生命周期。在你知道之前，微软可能会宣布另一种数据访问技术。他们似乎每3 - 5年就这样做... :) DAO，RDO，ODBC，ADO，OLEDB，ADO.NET，类型化数据集，ObjectSpaces，WinFS，L2S，EF，等等。我写的代码15几年前，针对DAO的应用仍在市场上，尽管DAO已经“死”多年，它仍然有效。
有时名称会被重新用于全新的数据访问技术，但这并没有改变这样一个事实，即微软最新的数据库访问技术是一个不断变化的目标......
答案 2 :(得分：4)
L2S不会去任何地方。 VS团队已经明确表达了这一点。它不会得到显着的改善，但它仍然会存在并且工作正常。
L2S非常棒，易于用于具有相当简单数据模型的小规模项目。触发我，何时选择EF而不是L2S，如果我有多对多的表，或者我需要在不止一个表上映射更复杂的实体。
答案 3 :(得分：3)
我们刚刚从VS 2008升级到VS 2010，从L2S升级到EF。
尽管我们以与L2S非常相似的方式使用EF，但我知道如果需要，我可以灵活地进行更高级的ORM。
那说 - 对于一个小项目 - 我可能仍然会使用L2S。大中型项目我会使用EF。
此外 - EF似乎是一个很大的学习曲线，因为EF文档促使我们开始研究一些设计模式，如工作单元，存储库，依赖注入。但是我意识到这些模式适用于L2S以及EF。
就Nhibernate而言 - 我的研究（即浏览SO）表明最新版本的EF4.0已经足够先进（POCO支持等），被认为是一种有竞争力的产品。
答案 4 :(得分：3)
我知道原始查询可能为时已晚，但为了将来有类似问题的人......
在我看来，关键的方面是你是在做一个全新的项目还是使用遗留数据库。我正在使用遗留数据库，有一些相当特殊的设计决策。我想使用EF，但它根本无法映射这些特性，而L2S管理得非常好。
例如。一些FK包含其他值而不是相关行的键 - 有效地加倍作为FK /标志列。
此外，FK继承映射完全失败了，因此我选择了一个扁平的L2S模型，以便在查询时获得类型检查和名称检查的好处，但结束了构建我自己的映射层。
所有这一切都是一种可怕的痛苦，如果对MS有任何安慰，我也发现NHibernate无法完成任务。根据我的经验，在实际使用中，太多的DB都存在这些问题，因此我建议EF不适合棕地开发。
对于新项目，您可以随意改进数据库设计以符合框架的假设。我不能这样做，因为现有的应用程序依赖于数据设计。我们希望逐步改进设计，但是尝试预先纠正所有问题会导致不可思议的大型迁移事件（对于我们的资源）。
注意：在英国（至少），棕地开发正在建造以前开发过的土地上的房屋。绿地开发正在建设我们日益减少的农村资源。我在这里重复了这些术语。
答案 5 :(得分：1)
如果第三方产品适合您，请尝试使用LinqConnect。该产品允许您使用不同的DBMS（Oracle，MySQL，PostgreSQL等）使用Linq to SQL（带有一些修改）。
LinqConnect为您提供以前在L2S中不可用的功能：
至于表现，我们提供商OrmBattle的最新比较测试是领导者之一。
此外，我们的DBMS-specific providers也支持所有EF功能。