Linq to Entities 与 ESQL 的性能对比答案

【问题标题】：Performance of Linq to Entities vs ESQLLinq to Entities 与 ESQL 的性能对比
【发布时间】：2010-09-07 12:11:48
【问题描述】：

使用实体框架时，ESQL 的性能是否优于 Linq to Entities？

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

【问题讨论】：

标签： entity-framework linq-to-entities entity-sql

【解决方案1】：

最明显的区别是：

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

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

不太明显的关键区别是：

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

无法使用 Entity SQL 进行投影，因为您必须始终返回 ObjectQuery。在某些情况下，可以使用 ObjectQuery

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;
}

其中一位团队成员详细描述了here 和here 的其他更细微的差异。

【讨论】：

【解决方案2】：

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

用 Linq 做了同样的事情，编译后的代码更易于管理，比如说 20 行 SQL。

另外，其他人提到的，Linq 是强类型，虽然如果没有编辑和继续功能进行调试非常烦人。

【讨论】：

【解决方案3】：

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

我相信 LINQ 也允许您预编译查询，这可能会给您带来更好的性能。 Rico Mariani blogged about LINQ performance 不久前讨论了编译查询。

【讨论】：

【解决方案4】：

在此处显示性能比较的漂亮图表： Entity Framework Performance Explored ESQL 和实体之间没有太大区别但在使用实体而不是直接查询方面总体差异显着

Entity Framework 使用两层对象映射（与 LINQ to SQL 中的单层相比），额外的映射具有性能成本。至少在 EF 版本 1 中，应用程序设计人员只有在建模和 ORM 映射功能可以证明成本合理时才应该选择实体框架。

【讨论】：

【解决方案5】：

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

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

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

【讨论】：

【解决方案6】：

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

【讨论】：