当前位置：文江博客话题详情

Linq to Entities 与 ESQL 的性能

发布于 2024-07-04 19:31:55 字数 160 浏览 8 评论 0原文

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦在夏天 2024-07-11 19:31:55

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

回复收藏 0 原文

孤凫 2024-07-11 19:31:55

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

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

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

回复收藏 0 原文

自找没趣 2024-07-11 19:31:55

漂亮的图表显示了性能比较：
实体框架性能探索
ESQL 和实体之间没有太大区别
但与直接查询相比，使用实体的总体差异很大。

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

回复收藏 0 原文

深海不蓝 2024-07-11 19:31:55

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

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

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

回复收藏 0 原文

再浓的妆也掩不了殇 2024-07-11 19:31:55

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

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

回复收藏 0 原文

动次打次papapa 2024-07-11 19:31:55

最明显的区别是：

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

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

The most obvious differences are:

Linq to Entities is strongly typed code including nice query comprehension syntax. The fact that the “from” comes before the “select” allows IntelliSense to help you.

Entity SQL uses traditional string based queries with a more familiar SQL like syntax where the SELECT statement comes before the FROM. Because eSQL is string based, dynamic queries may be composed in a traditional way at run time using string manipulation.

The less obvious key difference is:

Linq to Entities allows you to change the shape or "project" the results of your query into any shape you require with the “select new{... }” syntax. Anonymous types, new to C# 3.0, has allowed this.

Projection is not possible using Entity SQL as you must always return an ObjectQuery<T>. In some scenarios it is possible use ObjectQuery<object> however you must work around the fact that .Select always returns ObjectQuery<DbDataRecord>. See code below...

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

There are other more subtle differences described by one of the team members in detail here and here.

回复收藏 0 原文

~没有更多了~