Linq to Entities 与 ESQL 的性能对比

StackOverflow https://stackoverflow.com/questions/38647

题

使用实体框架时，ESQL 的性能是否比 Linq to Entities 更好？

我更喜欢使用 Linq to Entities（主要是因为强类型检查），但我的其他一些团队成员将性能作为使用 ESQL 的理由。我想全面了解使用这两种方法的优点/缺点。

有帮助吗？

解决方案

最明显的区别是：

Linq to Entities 是强类型代码，包括良好的查询理解语法。事实上，“from”位于“select”之前，IntelliSense 可以为您提供帮助。

Entity SQL 使用传统的基于字符串的查询以及更熟悉的类似 SQL 的语法，其中 SELECT 语句位于 FROM 之前。由于 eSQL 是基于字符串的，因此可以在运行时使用字符串操作以传统方式组成动态查询。

不太明显的关键区别是：

Linq to Entities 允许您使用“select new{...”更改形状或将查询结果“投影”为您需要的任何形状。}“ 句法。C# 3.0 中新增的匿名类型允许这样做。

使用 Entity SQL 无法进行投影，因为您必须始终返回 ObjectQuery<T>。在某些情况下，可以使用 ObjectQuery<object>，但是您必须解决 .Select 始终返回 ObjectQuery<DbDataRecord> 的事实。请参阅下面的代码...

ObjectQuery<DbDataRecord> query = DynamicQuery(context,
        "Products",
        "it.ProductName = 'Chai'",
        "it.ProductName, it.QuantityPerUnit");

public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
    ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
    ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
    ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
    return result;
}

一位团队成员详细描述了其他更细微的差异 这里 和 这里.

其他提示

ESQL还可以生成一些特别恶意的sql。我必须跟踪这样一个使用继承类的查询的问题，我发现我的 4 行小 ESQL 被翻译成一个 100000 个字符的怪物 SQL 语句。

使用 Linq 做了同样的事情，编译后的代码更易于管理，假设有 20 行 SQL。

另外，正如其他人提到的，Linq 是强类型的，尽管在没有编辑和继续功能的情况下调试起来非常烦人。

广告

Entity-SQL (eSQL) 允许您比 LINQ to Entities 更轻松地执行动态查询等操作。但是，如果您没有需要 eSQL 的场景，我会犹豫是否要依赖它而不是 LINQ，因为它会更难维护（例如，不再进行编译时检查等）。

我相信 LINQ 还允许您预编译查询，这可能会给您带来更好的性能。里科·马里亚尼 发表有关 LINQ 性能的博客 不久前讨论了编译查询。

漂亮的图表显示了性能比较： 实体框架性能探索ESQL和实体之间没有太大的差异，但总体差异在使用实体而不是直接查询的情况下显着

实体框架使用两层对象映射（与 LINQ to SQL 中的单层相比），并且额外的映射会产生性能成本。至少在 EF 版本 1 中，仅当建模和 ORM 映射功能能够证明该成本合理时，应用程序设计人员才应选择实体框架。

对我来说，通过编译时间检查可以覆盖的代码越多，我就越看重性能。话虽如此，在这个阶段我可能会倾向于 ESQL，不仅仅是因为它的性能，而且（目前）它的功能也更加灵活。没有什么比使用不具备您真正需要的功能的技术堆栈更糟糕的了。

实体框架不支持自定义属性、自定义查询（当您需要真正调整性能时），并且功能与 linq-to-sql 不同（即有些功能在实体框架中根本不起作用）。

我个人对实体框架的印象是，它有很大的潜力，但在当前状态下的生产环境中使用它的实现可能有点“僵化”。

对于直接查询，我使用 linq toEntity，对于动态查询，我使用 ESQL。也许答案不是非此即彼，而是和/也。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top