在过去一周里,我一直在阅读博客圈,Linq到sql已经死亡[和长期的EF和Linq到实体].但是当我阅读MSDN的概述时,我看起来Linq to Entities生成的esql只是Linq to sql生成SQL查询的方式.
@H_301_2@现在,由于底层实现(并且自从sql Server还不是ODBMS)仍然是一个关系存储,在某些时候,Entity框架必须将其转换成SQL查询.为什么不将Linq修复到sql问题(m：m关系,只有sql服务器支持等),并将Linq作为生成这些查询的层使用sql？
@H_301_2@这是因为性能还是EF使用不同的方式将esql语句转换成sql？
@H_301_2@在我看来 – 至少对于我未经考虑的心灵来说,这是一种自然而然的方式,可以将Linq转换为EF中的sql.
@H_301_2@注释？
解决方法
值得注意的是,实体框架(至少)有三种被消费的方式：
@H_301_2@> LINQ to Entities over Object Services over Entity Client
>通过实体客户端的对象服务实体sql
>实体sql使用Entity Client命令对象(最常见于经典ADO.NET) @H_301_2@实体客户端最终会抛出Esql命令的表示(以规范的数据库不可知形式),特定RDBMS的ADO.NET提供程序负责转换为特定于存储库的sql.这是正确的模型IMHO,因为多年来投入了大量时间(并将继续投资),为每个商店生产优质的ADO.NET提供商. @H_301_2@由于实体框架需要与许多商店一起使用,因此许多ADO.NET提供商的优势在于,它们可以轻松地优化Entity Client在每个商店基础上生成的内容(至少是我们与v1的位置). LINQ to sql团队解决的问题要小得多 – “仅适用于sql Server”,因此可以更容易地存储特定的东西.我知道EF团队知道,有一些情况下,EF到sql Server生产的Tsql效率比L2S低,正在努力改进V2. @H_301_2@有趣的是,此模型允许在实体客户端和商店的ADO.NET提供商之间添加新功能.这些“包装提供商”可以添加诸如日志记录,审核,安全性,缓存等服务.这被描述为在http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx的V2功能 @H_301_2@如果你看到更大的图像,你可以看到,尝试和以某种方式将L2S Tsql生成改造成实体框架的构造将是非常困难和限制性的.
>通过实体客户端的对象服务实体sql
>实体sql使用Entity Client命令对象(最常见于经典ADO.NET) @H_301_2@实体客户端最终会抛出Esql命令的表示(以规范的数据库不可知形式),特定RDBMS的ADO.NET提供程序负责转换为特定于存储库的sql.这是正确的模型IMHO,因为多年来投入了大量时间(并将继续投资),为每个商店生产优质的ADO.NET提供商. @H_301_2@由于实体框架需要与许多商店一起使用,因此许多ADO.NET提供商的优势在于,它们可以轻松地优化Entity Client在每个商店基础上生成的内容(至少是我们与v1的位置). LINQ to sql团队解决的问题要小得多 – “仅适用于sql Server”,因此可以更容易地存储特定的东西.我知道EF团队知道,有一些情况下,EF到sql Server生产的Tsql效率比L2S低,正在努力改进V2. @H_301_2@有趣的是,此模型允许在实体客户端和商店的ADO.NET提供商之间添加新功能.这些“包装提供商”可以添加诸如日志记录,审核,安全性,缓存等服务.这被描述为在http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx的V2功能 @H_301_2@如果你看到更大的图像,你可以看到,尝试和以某种方式将L2S Tsql生成改造成实体框架的构造将是非常困难和限制性的.
