IEnumerable 和 IQueryable - 两全其美

Question

出于性能原因，我的许多服务现在都返回 IQueryable，因此调用者可以决定在具体化之前过滤哪些元素。出于设计原因（接口等），我宁愿返回 IEnumerables，但这肯定会消除 IQueryables 的优势：完整结果集的实现加上没有 -Async 方法。

我已经开始编写一些更喜欢 IQueryable 而不是 IEnumerable 的扩展方法，例如：

public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Expression<Func<TSource, bool>> predicate)
    => source is IQueryable<TSource> ? Queryable.Where(source as IQueryable<TSource>, predicate) : Enumerable.Where(source, predicate.Compile());

public static Task<TSource[]> ToArrayAsync<TSource>(this IEnumerable<TSource> source)
    => (source as IQueryable<TSource>)?.ToArrayAsync() ?? Task.FromResult(source.ToArray());

我不可能是唯一一个在想这个的人。这些方法有什么改进吗？那里已经有很好的收藏/解决方案了吗？或者这是一个糟糕的设计？所以请告诉我原因。

谢谢！

Answer 1

就我个人而言，这会让我变得谨慎；序列和查询是相似的，但又足够不同，我非常想确定它是如何处理的。在生成表达式树然后编译它时也有一些重要的开销，而不是在捕获上下文上使用直接编译器生成的方法。表达式树的开销是合理的，如果它将被用作查询组合和翻译的一部分，但在序列案例中不需要。

也许更明显的方法是在序列上使用AsQueryable() 来模拟真正的查询。

但是：我猜你所拥有的应该可以工作。作为一个小的语法说明，在最近的 C# 版本中，您可以将类型化的值捕获为 is 的一部分，以避免双重转换：

public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Expression<Func<TSource, bool>> predicate)
    => source is IQueryable<TSource> q ? Queryable.Where(q, predicate) : Enumerable.Where(source, predicate.Compile());

尝试Compile() 上的布尔标志可能也很有趣——使用解释模式会降低执行速度，但会避免生成 IL。它可能对小数据集产生积极影响，而对大数据集产生负面影响。

附带说明：可查询源有多种异步实现； EF Core 有一个，而 IX（Reactive 的一部分）有另一个。它们彼此不兼容并使用不同的方法，但两者都可以根据您的情况工作。