过去一周我一直在博客圈上读到 Linq to SQL 已死[而 EF 和 Linq to Entities 万岁]。但当我阅读 MSDN 上的概述时，我发现 Linq to Entities 生成 eSQL 的方式与 Linq to SQL 生成 SQL 查询的方式相同。
现在，由于底层实现（并且由于 SQL Server 还不是 ODBMS）仍然是关系存储，因此实体框架在某些时候必须转换为 SQL 查询。为什么不修复 Linq to SQL 问题（m:m 关系、仅 SQL Server 支持等）并使用 Linq to SQL 作为生成这些查询的层？
这是因为性能原因还是 EF 使用不同的方式将 eSQL 语句转换为 SQL？
在我看来（至少对于我没有学问的头脑来说），这似乎很适合在 EF 中测试 Linq to SQL。
评论？
值得注意的是，实体框架（至少）有三种使用方式：
- 通过实体客户端的对象服务的 LINQ to Entities
- 实体 SQL 通过对象服务通过实体客户端
- 使用实体客户端命令对象的实体 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 提供程序之间添加新功能。这些“包装提供者”可以添加日志记录、审计、安全性、缓存等服务。这是作为 V2 功能进行讨论的http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx
如果您从更大的角度来看，您会发现尝试以某种方式将 L2S TSQL 生成改造到实体框架的体系结构中将非常困难，而且确实受到限制。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
