EntityFramework Core 在.NET 9中的子查询扩展方法翻译问题解析

问题背景

在从.NET 8升级到.NET 9后，一些开发者发现原本正常工作的EntityFramework Core查询出现了问题。具体表现为：当在子查询或子表达式中使用IQueryable的扩展方法时，这些扩展方法无法被正确翻译为SQL，导致运行时抛出异常。

问题现象

典型的问题场景出现在使用Join操作时，其中内联查询使用了自定义的扩展方法。例如：

var myResults = _myContext.Customers
    .Join(
        _myContext.Points
            .ExcludeDeleted()
            .ExcludePointsNotInUse(),
        customer => customerId,
        point => point.customerId,
        (customer, point) => new {customer, point});

其中ExcludeDeleted()是一个简单的扩展方法：

internal static IQueryable<PointState> ExcludeDeleted(this IQueryable<PointState> queryable)
{
    return queryable.Where(p => p.DeletionState.State != DigitalTwinItemDeletionState.Deleted.State);
}

在.NET 9中，这种写法会导致EF Core无法正确翻译整个查询表达式，抛出翻译失败的异常。而在之前的.NET版本(5-8)中，相同代码可以正常工作。

临时解决方案

目前可行的临时解决方案是将子查询部分提取到单独的变量中：

var pointsInUse = _myContext.Points
            .ExcludeDeleted()
            .ExcludePointsNotInUse();

var myResults = _myContext.Customers
    .Join(
        pointsInUse,
        customer => customerId,
        point => point.customerId,
        (customer, point) => new {customer, point});

这种写法在.NET 9中可以正常工作，说明问题可能与表达式树的构建和解析方式有关。

技术分析

这个问题实际上与早期EF6中的一个已知问题类似。在查询翻译过程中，EF Core需要能够识别并处理整个表达式树。当扩展方法被直接内联在子查询中时，.NET 9可能采用了不同的表达式树构建或解析策略，导致翻译器无法正确识别这些扩展方法。

值得注意的是，在简单的测试案例中，这个问题无法复现，说明它可能只在特定复杂度的查询组合中才会显现。这提示我们：

1. 问题可能与表达式树的深度或复杂度有关
2. 可能涉及特定类型的查询操作组合
3. 可能与上下文配置或模型定义有某种关联

最佳实践建议

1. 查询分解：对于复杂查询，特别是包含子查询的情况，考虑将查询分解为多个部分，使用中间变量存储子查询结果。

2. 扩展方法设计：确保自定义的查询扩展方法尽可能简单，只包含EF Core能够翻译的标准LINQ操作。

3. 版本兼容性测试：在升级EF Core或.NET版本时，对复杂查询进行充分测试。

4. 监控官方更新：关注EF Core团队的官方发布说明，了解是否有相关修复或行为变更。

总结

这个问题展示了框架升级可能带来的微妙兼容性问题。虽然目前可以通过查询重构来解决，但开发者需要意识到这种潜在的变化。对于关键业务系统中的复杂查询，建议在升级前进行全面测试，并准备好必要的代码调整方案。

EF Core团队通常会快速响应这类回归问题，因此建议开发者关注后续的更新和修复。同时，保持查询代码的简洁和模块化，可以最大程度地减少这类问题的发生概率和影响范围。