过去一周，我一直在博客圈上看到 Linq to SQL 已死 [EF 和 Linq to Entities 万岁]。但是当我阅读 MSDN 上的概述时，在我看来 Linq to Entities 生成 eSQL 就像 Linq to SQL 生成 SQL 查询一样。
现在，由于底层实现（并且由于 SQL Server 还不是 ODBMS）仍然是关系存储，在某些时候实体框架必须将转换为 SQL 查询。为什么不修复 Linq to SQL 问题（m:m 关系，仅支持 SQL 服务器等）并使用 Linq to SQL in 作为生成这些查询的层？
这是因为性能还是 EF 使用不同的方式将 eSQL 语句转换为 SQL？
在我看来 - 至少对于我没有学识的头脑来说 - 很自然地适合在 EF 中将 Linq 转为 SQL。
评论？
值得注意的是，Entity Framework（至少）有三种消费方式：
实体客户端最终会输出 ESQL 命令的表示（以规范的、与数据库无关的形式），特定 RDBMS 的 ADO.NET 提供程序负责将其转换为存储特定的 SQL。恕我直言，这是正确的模型，因为多年来已经投入（并将继续投入）为每个商店制作出色的 ADO.NET 提供程序。
由于 Entity Framework 需要与许多商店一起工作，因此需要与许多 ADO.NET 提供程序一起工作，因此他们无法轻松优化实体客户端在每个商店的基础上生成的内容（至少 - 这就是我们使用 v1 的地方）。LINQ to SQL 团队要解决的问题要小得多——“仅适用于 SQL Server”，因此可以更轻松地存储特定内容。我知道 EF 团队知道在某些情况下，EF 到 SQL Server 生成 TSQL 的效率低于 L2S，并且正在努力改进 V2 的这一点。
有趣的是，此模型允许在实体客户端和 ADO.NET 提供程序之间为商店添加新功能。这些“包装提供者”可以添加诸如日志记录、审计、安全、缓存等服务。这在http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx上作为 V2 功能进行了讨论
如果您从更大的角度来看，您会发现尝试以某种方式将 L2S TSQL 生成改进到实体框架的体系结构中将非常困难并且确实受到限制。
实际上，EF 在翻译 LINQ 查询时不会生成 EntitySQL。在 EF 中，我们为所有查询提供了基于数据结构的表示，称为 CQT 或规范查询树。LINQ 翻译器和 EntitySQL 解析器都产生 CQT，查询翻译管道的其余部分使用 CQT（和其他内部中间形式），经过各种转换后，它到达 ADO.NET 提供程序（作为存储级 CQT），然后负责将其翻译成后端的 SQL 方言。所以路径是 LINQ -> CQT -> SQL 或 EntitySQL -> CQT -> SQL。
Linq to SQL 和 Entity Framework 之间的一个很大区别是 EF 实现了实体数据模型规范 (EDM)，并且还有其他围绕 EDM 构建的产品，例如 ADO.NET Data Services（又名 Astoria）。
EDM 现在被用于在名为开放数据协议 (OData http://odata.org/ ) 的新规范中扩展 AtomPub，该规范用于在 REST 之上标准化 CRUD。