实体框架和LINQ to SQL – 利益冲突？
|
在过去一周里,我一直在阅读博客圈,Linq到SQL已经死亡[和长期的EF和Linq到实体].但是当我阅读MSDN的概述时,我看起来Linq to Entities生成的eSQL只是Linq to SQL生成SQL查询的方式.
现在,由于底层实现(并且自从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 实体客户端最终会抛出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功能 如果你看到更大的图像,你可以看到,尝试和以某种方式将L2S TSQL生成改造成实体框架的构造将是非常困难和限制性的. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |