过去一周我一直在博客圈上读到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-SQLin作为生成这些查询的层？
这是因为性能还是EF使用了不同的方式将eSQL语句转换为SQL？
在我看来——至少对于我那未经学习的头脑来说——这是一种天生的适合在EF中把Linq比作SQL的方式。
评论？
值得注意的是，实体框架（至少）有三种消费方式：
- LINQ to Entity over Object Services over Entity Client
- 实体SQL over对象服务over实体客户端
- 使用实体客户端命令对象的实体SQL（最类似于经典的ADO.NET）
实体客户端最终抛出一个ESQL命令的表示（以规范的、与数据库无关的形式）。NET提供程序负责将特定的RDBMS转换为特定于存储的SQL。这是IMHO的正确模式，因为多年来，在制作伟大的ADO方面投入了大量时间（并将继续投入）。NET提供程序。
由于实体框架需要处理许多存储，因此需要处理许多ADO。NET提供商——他们在每个商店的基础上轻松优化实体客户端生成的内容的空间较小（至少——这就是我们使用v1的地方）。LINQ to SQL团队有一个小得多的问题需要解决——"仅适用于SQL Server"，因此可以更容易地完成存储特定的内容。我知道EF团队意识到，在某些情况下，EF到SQL Server生成TSQL的效率低于L2S，并且正在为V2改进这一点。
有趣的是，这个模型允许在实体客户端和ADO之间添加新的功能。NET提供程序。这些"包装提供者"可以添加日志记录、审核、安全性和缓存等服务。这作为V2功能在http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx
如果你从更大的角度来看，你会发现尝试以某种方式将L2S-TSQL生成改造到实体框架的体系结构中是非常困难的，而且确实是限制性的。
实际上，EF在转换LINQ查询时不会生成EntitySQL。在EF中，我们为所有查询提供了一种基于数据结构的表示，称为CQT或规范查询树。LINQ翻译器和EntitySQL解析器都生成CQT，查询翻译管道的其余部分使用CQT（和其他内部中间形式），这些CQT经过各种转换后到达ADO。NET提供程序（作为存储级CQT），然后负责将其转换为后端的SQL方言。因此路径是LINQ->CQT->SQL或EntitySQL->CQT->SQL。
Linq-to-SQL和实体框架之间的一大区别是EF实现了实体数据模型规范（EDM），还有其他围绕EDM构建的产品，如ADO。NET数据服务（又名Astoria）。
EDM现在被用于在一个名为开放数据协议（OData）的新规范中扩展AtomPubhttp://odata.org/)，用于在REST之上标准化CRUD。