这两个产品现在的情况如何？我似乎找不到任何关于VS2010/.net 4.0特别问题的信息。
在.net 3.5时代，大多数人认为当.net 4.0推出时，Linq2SQL将会消失，但它似乎仍然存在并且表现良好。
另一方面，EF 4.0似乎得到了显着的改进。
对于我来说，我的大部分工作都是小型到中型项目，并且公司很快就要从VS08迁移到VS10。我应该关注什么？或者说，我应该花时间学习EF4.0还是NHibernate更好呢？（但回到主题，我真的更感兴趣的是Linq2Sql-EF。）
最后，我目前正在使用entlib / unity，哪个框架更适合依赖/策略注入？
提前致谢。
1 - L2SQL基本上已经过时了
2 - L2SQL不支持POCO映射，EF则支持。
3 - EF更加灵活（代码优先、模型优先、数据库优先）。L2SQL只有一个。
4 - EF支持SPROC->POCO映射
5 - EF具有Entity-SQL，允许您在必要时返回到经典的ADO.NET
6 - EF支持继承（TPT，TPH）
7 - EF与仓储模式和通过IQueryable进行延迟执行密切相关
8 - EF组件（ObjectSet，ObjectContext）易于模拟并允许DI
我想不出任何新项目使用L2SQL的理由。
有些人可能会说“好吧，L2SQL对于小项目来说很好，我可以拖放完成”。
好吧，您也可以使用EF4，如果您决定修改/增大项目，则长期而言将拥有更多的灵活性/支持。所以这不是借口。
希望对你有帮助。
在前面的回答和评论中（我都点了+1），还有以下两点需要补充：
a) 性能: L2S 运行时比 EF 更轻量级（因为只有一个层；EF 则涉及两个模型层以及它们之间的映射）。
EF 通常会生成比 L2S 更冗长的 TSQL，但大多数情况下这只会影响到查询性能分析时的可读性。 SQL 优化器大部分时间最终仍会生成相同的执行计划。然而，有些情况下查询可能会变得非常庞大和复杂，这可能会对性能产生影响。
L2S 在客户端优化查询方面也稍微好一些；它可以消除可以在客户端评估的 where 子句谓词，从而使数据库不必再关心这些谓词。这意味着 SQL Server 的优化器处理更少的工作，同时也降低了出现“糟糕”执行计划的风险。
b) L2S vs L2E: 当将普通 CLR 方法用于 LINQ 查询时，L2S 相对于 L2E 转换成 TSQL 的能力仍略优，特别是在 DateTime 和相关方法上。L2E 支持的功能与 L2S 大致相同，但是通过自己的 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 已经“死”了多年，但它仍然能够正常工作。
有时会为全新的数据访问技术重新使用名称，但这并不改变微软最新的数据库访问技术是一个不断变化的目标的事实...
L2S并没有被淘汰。VS团队已经明确表示，它不会得到重大改进，但仍然会存在并且可以正常使用。
L2S很棒，对于数据模型相对简单的小型项目来说非常易用。我在何时选择EF而不是L2S的判断标准是：当我有多对多表格或需要映射更复杂的实体到不止一个表格时。
我们刚刚从VS 2008迁移到了VS 2010，并且从L2S转向了EF。
尽管我们使用EF的方式与L2S非常相似，但让我感到舒适的是，如果需要，我有灵活性来执行更高级的ORM操作。
话虽如此 - 对于小型项目 - 我可能仍然会使用L2S。对于中型到大型项目，我会使用EF。
另外 - EF似乎是一个很大的学习曲线，因为EF文档提示我们开始研究一些设计模式，如Unit Of Work、Repository、Dependency Injection。然而，我意识到这些模式也适用于L2S。
就NHibernate而言 - 我的研究（即浏览SO）表明，EF4.0的最新版本已足够先进（支持POCO等）可以被视为竞争产品。
