ToAsyncEnumerable().Single() 与 SingleAsync() [英] ToAsyncEnumerable().Single() vs SingleAsync()

问题描述

我正在以独立于 EF-Core 的方式构建和执行我的查询，因此我依靠 IQueryable 来获得所需的抽象级别.我正在用等待的 ToAsyncEnumerable().Single() 调用替换等待的 SingleAsync() 调用.我还将 ToListAsync() 调用替换为 ToAsyncEnumerable().ToList() 调用.但我刚刚遇到了 ToAsyncEnumerable() 方法，所以我不确定我是否正确使用它.

I'm constructing and executing my queries in a way that's independent of EF-Core, so I'm relying on IQueryable<T> to obtain the required level of abstraction. I'm replacing awaited SingleAsync() calls with awaited ToAsyncEnumerable().Single() calls. I'm also replacing ToListAsync() calls with ToAsyncEnumerable().ToList() calls. But I just happened upon the ToAsyncEnumerable() method so I'm unsure I'm using it correctly or not.

为了阐明我所指的扩展方法，它们的定义如下:

To clarify which extension methods I'm referring to, they're defined as follows:

• SingleAsync 和 ToListAsync 在 Microsoft.EntityFrameworkCore 命名空间和程序集中的 EntityFrameworkQueryableExtensions 类上定义.
• ToAsyncEnumerable 在 System.Interactive.Async 命名空间中的 AsyncEnumerable 类上定义> 组装.

• SingleAsync and ToListAsync are defined on the EntityFrameworkQueryableExtensions class in the Microsoft.EntityFrameworkCore namespace and assembly.
• ToAsyncEnumerable is defined on the AsyncEnumerable class in the System.Linq namespace in the System.Interactive.Async assembly.

当查询针对 EF-Core 运行时，调用 ToAsyncEnumerable().Single()/ToList() 与 SingleAsync()/ToListAsync() 是否等效于功能和性能?如果不是，那么它们有何不同?

When the query runs against EF-Core, are the calls ToAsyncEnumerable().Single()/ToList() versus SingleAsync()/ToListAsync() equivalent in function and performance? If not then how do they differ?

推荐答案

对于返回序列的方法(如 ToListAsync、ToArrayAsync)，我不希望有什么不同.

For methods returning sequence (like ToListAsync, ToArrayAsync) I don't expect a difference.

但是对于单值返回方法(First、FirstOrDefault、Single、Min 的异步版本，Max、Sum 等)肯定会有区别.这与在 IQueryable 和 IEnumerable 上执行这些方法的区别相同.在前一种情况下，它们由数据库查询处理，返回单个值给客户端，而在后一种情况下，整个结果集将返回给客户端并在内存中处理.

However for single value returning methods (the async versions of First, FirstOrDefault, Single, Min, Max, Sum etc.) definitely there will be a difference. It's the same as the difference by executing those methods on IQueryable<T> vs IEnumerable<T>. In the former case they are processed by database query returning a single value to the client while in the later the whole result set will be returned to the client and processed in memory.

因此，虽然总体上抽象 EF Core 的想法是好的，但它会导致 IQueryable 的性能问题，因为可查询的异步处理未标准化，并转换为 IEnumerable 改变了执行上下文，因此实现了单值返回 LINQ 方法.

So, while in general the idea of abstracting EF Core is good, it will cause performance issues with IQueryable<T> because the async processing of queryables is not standartized, and converting to IEnumerable<T> changes the execution context, hence the implementation of single value returning LINQ methods.

附言通过标准化，我的意思如下.IQueryable 的同步处理由 IQueryProvider(System.Linq 命名空间中的标准接口提供).Core.dll 程序集)Execute 方法.异步处理需要引入另一个类似于 EF Core 自定义 IAsyncQueryProvider(在 Microsoft.EntityFrameworkCore.Query.Internal 内)的标准接口> Microsoft.EntityFrameworkCore.dll 程序集中的命名空间).我想这需要 BCL 团队的合作/批准并且需要时间，这就是他们决定现在采用自定义路径的原因.

P.S. By standardization I mean the following. The synchronous processing of IQueryable is provided by IQueryProvider (standard interface from System.Linq namespace in System.Core.dll assembly) Execute methods. Asynchronous processing would require introducing another standard interface similar to EF Core custom IAsyncQueryProvider (inside Microsoft.EntityFrameworkCore.Query.Internal namespace in Microsoft.EntityFrameworkCore.dll assembly). Which I guess requires cooperation/approval from the BCL team and takes time, that's why they decided to take a custom path for now.

这篇关于ToAsyncEnumerable().Single() 与 SingleAsync()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！