实体框架和LINQ To SQL - 感兴趣的冲突？

Question

过去一周，我一直在博客上看到Linq to SQL已经死了[和长期的EF和Linq to Entities]。但是当我阅读MSDN上的概述时，我发现Linq实体生成eSQL只是Linq to SQL生成SQL查询的方式。

现在，由于底层实现（并且因为SQL Server还不是ODBMS）仍然是一个关系存储，所以实体框架在某个时刻必须将翻译转换为SQL查询。为什么不修复Linq到SQL问题（m：m关系，只有SQL服务器支持等），并使用Linq to SQL作为生成这些查询的图层？

这是因为性能还是EF使用不同的方式将eSQL语句转换为SQL？

在我看来，至少对于我没有经验的人来说，这是一种天生适合在EF中使用Linq to SQL的食物。

评论？

Answer 1

值得注意的是实体框架有（至少）被消耗的方式有三种：

• LINQ到了实体客户端实体在对象服务
• 实体SQL在对象服务在实体客户端
• 实体SQL使用实体客户端命令对象（最类似于传统的ADO.NET）

实体客户端最终吐出ESQL命令的表示（在一个规范的，数据库不可知的表单），用于特定RDBMS的ADO.NET提供程序负责转换为存储特定的SQL。这是多年来的正确模式，因为多年来已投入大量时间（并将继续投入）为每家商店生产优秀的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代入实体框架的archiecture讨论。

Answer 2

Linq到SQL和实体框架之间的一个很大的区别是EF实现了实体数据模型规范（EDM），还有其他围绕EDM构建的产品，如ADO.NET数据服务（又名Astoria）。

EDM现在被用于扩展AtomPub在一个名为开放数据协议（OData http://odata.org/）的新规范中，该规范用于在REST之上标准化CRUD。

Answer 3

其实，翻译LINQ查询时，EF不会产生EntitySQL。在EF中，我们为所有查询（称为CQT或规范查询树）提供了基于数据结构的表示形式。两者LINQ译者和EntitySQL解析器产生CQTs，并查询翻译流水线的其余部分使用CQTs（以及其它内部中间形式），其后各种变换使它的ADO.NET提供者（作为商店级CQT），然后负责将其转换为后端的SQL方言。所以路径是LINQ - > CQT - > SQL或EntitySQL - > CQT - > SQL。