现在,由于底层实现(并且自从sql Server还不是ODBMS)仍然是一个关系存储,在某些时候,Entity框架必须将其转换成SQL查询.为什么不将Linq修复到sql问题(m：m关系,只有sql服务器支持等),并将Linq作为生成这些查询的层使用sql？
这是因为性能还是EF使用不同的方式将esql语句转换成sql？
在我看来 – 至少对于我未经考虑的心灵来说,这是一种自然而然的方式,可以将Linq转换为EF中的sql.
注释？
解决方法
> LINQ to Entities over Object Services over Entity Client
>通过实体客户端的对象服务实体sql
>实体sql使用Entity Client命令对象(最常见于经典ADO.NET)
实体客户端最终会抛出Esql命令的表示(以规范的数据库不可知形式),特定RDBMS的ADO.NET提供程序负责转换为特定于存储库的sql.这是正确的模型IMHO,因为多年来投入了大量时间(并将继续投资),为每个商店生产优质的ADO.NET提供商.
由于实体框架需要与许多商店一起使用,因此许多ADO.NET提供商的优势在于,它们可以轻松地优化Entity Client在每个商店基础上生成的内容(至少是我们与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功能
