实体框架 Entity SQL 与实体框架 LINQ to Entities 的比较

Question

实体 SQL 的目的是什么，我的意思是如果你有 Linq to Entities，为什么需要编写字符串查询，是否有性能原因或其他原因？

- Omu

Answer 1

LINQ to Entities无法访问数据库的每个功能。有时候需要“深入”数据库进行高级查询，以便在第一时间完成查询或者改进LINQ to Entities系统对查询的糟糕选择。

尽管如此，我认为应该首先使用LINQ to Entities。如果性能成为问题，或者您有更复杂的问题，那么可以将该问题部分封装在存储过程中并调用它。现在没有理由使用字符串作为查询的基础。

- Godeke

Answer 2

ESQL允许您在where子句中选择排序规则，而这在LINQ-to-Anything中不受支持。这确实非常有用。ESQL还允许您指定要返回的精确类型，当类型从彼此继承时（与LINQ的OfType不同，后者返回某个类型和任何子类型的实例）。除此之外，我想不出使用它的好理由。有时能够在字符串中构建查询是很好的，但动态查询/动态LINQ通常已经足够，在极少数必要的情况下。

我认为（或许是愤世嫉俗地认为），ESQL的“真正”目的是“它早于LINQ”。

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

- Craig Stuntz

---

我的观点是关于次优查询，我可以在TSQL中做一些在LINQ to Entities中无法实现的事情。请在Google上搜索“parameter sniffing entities”以获取一些示例（或者，如果您有解决方法，请告诉我并帮助所有需要的人！）我发现可靠的一般解决方法是使用T-SQL来避免嗅探错误。 - Godeke

T-SQL，可以。大多数情况下不行的是ESQL。问题是LINQ vs. ESQL，而不是T-SQL。 - Craig Stuntz

ESQL = "Entity SQL"（EF 特定查询语言）。T-SQL = "Transact SQL"（SQL Server 特定查询语言）。它们完全不同，且都与 LINQ to Entities 不同。 - Craig Stuntz