entity-framework - Entity Framework 和 LINQ To SQL - 利益冲突？

Question

过去一周我一直在博客圈上看到 Linq to SQL 已经死了 [EF 和 Linq to Entities 万岁]。但是当我阅读 MSDN 上的概述时，在我看来，Linq to Entities 生成 eSQL 的方式与 Linq to SQL 生成 SQL 查询的方式相同。

现在，由于底层实现(并且因为 SQL Server 还不是 ODBMS)仍然是一个关系存储，在某些时候 Entity Framework 必须将转换为 SQL 查询。为什么不修复 Linq to SQL 问题(m:m 关系，仅 SQL 服务器支持等)并使用 Linq to SQL 作为生成这些查询的层？

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

在我看来 - 至少对于我未学过的头脑 - 很适合在 EF 中使用 Dogfood Linq to SQL。

评论？

Answer 1

值得注意的是，Entity Framework 有(至少)三种消费方式:

LINQ to Entity over Object Services over Entity Client

基于实体客户端的对象服务上的实体 SQL

使用实体客户端命令对象的实体 SQL(最类似于经典的 ADO.NET)

实体客户端最终会吐出 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 生成改造到 Entity Framework 的体系结构中将是非常困难的，并且确实具有限制性。