实体框架实体 sql 与 linq 到实体答案

【问题标题】：entity framework entity sql vs linq to entities实体框架实体 sql 与 linq 到实体
【发布时间】：2009-09-01 17:53:04
【问题描述】：

实体 sql 的目的是什么，我的意思是，如果您对实体有 linq，为什么需要在字符串中编写查询，是否有任何性能原因或什么？

【问题讨论】：

标签： sql entity-framework

【解决方案1】：

LINQ to Entities 不允许您访问数据库的所有功能。对于高级查询，有时需要能够“进入”数据库，或者首先将它们拉出来，或者改进 LINQ to Entities 系统有时会为您的查询做出可怕的选择。

也就是说，我认为 LINQ to Entities 应该是第一个使用的工具。如果性能成为问题，或者您有更复杂的事情，我会将该问题部分封装在存储过程中并调用它。现在没有理由将字符串用作查询的基础。

【讨论】：

【解决方案2】：

ESQL 允许您在 where 子句上选择排序规则，这是 LINQ-to-Anything 不支持的。这真的很有用。当类型相互继承时，ESQL 还允许您指定要返回的精确类型（与 LINQ 的 OfType 相反，它返回特定类型和任何子类型的实例）。除此之外，我想不出一个很好的理由来使用它。能够在字符串中构建查询偶尔会很不错，但 DynamicQuery/Dynamic LINQ 通常在极少数需要这样做的情况下就足够了。

我认为（也许是玩世不恭）ESQL 的“真正”目的是“它早于 LINQ”。

关于 Godeke 修复非最优查询的观点，我还没有看到通过更改 LINQ 表达式无法修复的问题。 ESQL 和 L2E 最终都是 CCT，因此 SQL 生成管道是相同的。

【讨论】：

关于次优查询的观点是，我可以在 TSQL 中做一些在 LINQ to Entities 中做不到的事情。使用“参数嗅探实体”在 Google 上浏览一些示例（或者，如果您有修复，请让我知道并帮助所有需要帮助的人！）我发现可靠的一般解决方法是使用 T-SQL以避免嗅探错误。
T-SQL，是的。 ESQL，不，在大多数情况下。问题是 LINQ 与 ESQL，而不是 T-SQL。
ESQL = "Entity SQL"（EF 特定的查询语言）。 T-SQL = "Transact SQL"（SQL Server 特定的查询语言）。它们完全不同，并且都不同于 LINQ to Entities。