实体框架和LINQ to SQL - 利益冲突？

过去一周,我一直在博客圈阅读Linq to SQL已经死亡[以及EF和Linq to Entities的长期存在].但是当我阅读MSDN上的概述时,我觉得Linq to Entities就像Linq to SQL生成SQL查询一样生成eSQL.

现在,由于底层实现(以及SQL Server还不是ODBMS)仍然是一个Relational存储,在某些时候,Entity框架必须转换为SQL查询.为什么不修复Linq to SQL问题(m:m关系,只有SQL服务器支持等)并使用Linq to SQL作为生成这些查询的层？

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

在我看来 - 至少对于我没有学过的头脑 - 在EF中自然适合Linq to SQL.

评论？

值得注意的是,实体框架(至少)有三种消费方式:

LINQ到实体客户端上的对象服务实体

实体客户端上的实体SQL over Object Services

使用Entity Client命令对象的Entity 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提供程序之间添加新功能.这些"包装提供程序"可以添加诸如日志记录,审计,安全性,缓存等服务.这在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解析器产生CQTs,并查询翻译流水线的其余部分使用CQTs(以及其它内部中间形式),其后各种变换使它的ADO.NET提供者(作为商店级CQT),然后负责将其翻译为后端的SQL方言.所以路径是LINQ - > CQT - > SQL或EntitySQL - > CQT - > SQL.