EF Core聚合查询中如何结合Specification模式使用？

1. 为何需要调用.ToArray()？该查询仍会被翻译为SQL在服务器执行，并未本地物化数据 #

EF Core 3.0+ 已经支持将.ToArray()这类集合操作直接翻译成SQL服务器端的子查询或聚合逻辑，不会真的把数据拉到本地内存。加.ToArray()的习惯大多来自早期EF版本：当时let语句中的IQueryable经常被EF错误判定为需要本地枚举的Enumerable，导致意外的客户端求值，加.ToArray()是用来强制EF将其翻译成服务器端子查询的“保险手段”。现在EF Core的翻译能力已经提升，但这种写法仍被不少开发者保留。

2. 为何不能不调用.ToArray()以保留IQueryable，从而能够应用规格？ #

不是完全做不到，而是容易触发EF Core的查询翻译限制。当你在let中保留IQueryable并尝试应用NSpecifications的规格（比如.Where(spec)）时，EF Core可能无法将规格中的表达式树正确整合到外层查询的SQL逻辑中——尤其是规格包含复杂条件（如多表关联、嵌套表达式）时，要么直接报错，要么被迫触发客户端求值（把数据拉到本地再过滤）。另外，NSpecifications的部分扩展方法如果未适配EF Core的表达式树解析规则，也会导致翻译失败。

3. 是否存在其他方法可继续使用规格模式解决上述问题？ #

有几种实用的解决方案：

• 直接在子查询中内嵌规格表达式：将规格转换为表达式树，直接写入子查询逻辑。例如定义NewOrderSpecification后，子查询可写为context.Orders.Where(x => x.RegionId == r.Id).Where(new NewOrderSpecification().ToExpression())，这样EF Core能直接解析整个表达式，生成正确的SQL。
• 利用投影时的条件聚合：如果目标是统计符合不同规格的订单数量，可在分组投影中结合Count与规格判断逻辑，比如new { RegionId = r.Id, NewOrders = context.Orders.Count(o => o.RegionId == r.Id && new NewOrderSpecification().IsSatisfiedBy(o)) }，前提是IsSatisfiedBy内的逻辑能被EF Core正确翻译。
• 封装子查询为可复用方法：编写扩展方法，比如GetOrdersForRegion(this DbContext ctx, int regionId, ISpecification<Order> spec)，内部返回ctx.Orders.Where(o => o.RegionId == regionId).Where(spec)，之后在主查询中调用该方法，EF Core通常能正确翻译方法内的表达式。
• 改用导航属性关联：如果Region与Order之间配置了导航属性（如Region.Orders），直接使用r.Orders.Where(spec)即可，EF Core对导航属性的表达式翻译支持更完善，能轻松结合规格模式。

内容的提问来源于stack exchange，提问作者Nick Farsi