EntityFramework Core 9.0 中 ColumnExpression 的架构变更解析

在 EntityFramework Core 9.0 版本中，开发团队对查询表达式树的内部实现进行了重要重构，特别是针对 ColumnExpression 类的设计变更。这一改动虽然属于底层架构调整，但对于需要深度定制 EF Core 查询行为的开发者而言具有重要意义。

旧版实现的问题

在 9.0 之前的版本中，ColumnExpression 直接持有对所属表的引用（通过 Table 属性），这种设计虽然直观，但在技术上存在两个显著问题：

1. 图结构隐患：表达式树本应是单纯的树形结构，但由于列与表之间的双向引用，实际上形成了图结构
2. 引用同步难题：当表引用发生变化时，需要手动维护所有相关列的引用一致性，容易产生同步错误

新版架构设计

9.0 版本进行了以下关键改进：

1. 去中心化引用：ColumnExpression 不再直接持有表引用，仅保留表别名（TableAlias）和列别名
2. 符合SQL语义：更贴近实际SQL语法（如 t.Id 这样的表达式结构）
3. 显式解析机制：需要通过表达式访问器（ExpressionVisitor）在遍历时主动维护表引用上下文

迁移指南

对于需要获取列所属表的场景，现在需要实现如下模式：

public class TableTrackingVisitor : ExpressionVisitor
{
    private readonly Dictionary<string, TableExpressionBase> _tables = new();
    
    protected override Expression VisitSelect(SelectExpression select)
    {
        // 记录当前作用域内的表引用
        foreach (var table in select.Tables)
        {
            _tables[table.Alias] = table;
        }
        
        return base.VisitSelect(select);
    }
    
    protected override Expression VisitColumn(ColumnExpression column)
    {
        // 通过别名解析实际表引用
        if (_tables.TryGetValue(column.TableAlias, out var table))
        {
            // 获取到列所属的table对象
        }
        return base.VisitColumn(column);
    }
}

典型应用场景

这种架构变更特别影响以下类型的扩展开发：

1. 查询验证（如强制要求排序规则）
2. 复杂查询重写
3. 自定义SQL生成逻辑

设计优势

新的架构带来了显著的稳定性提升：

• 消除了循环引用导致的序列化问题
• 降低了表达式树修改时的维护成本
• 为未来的查询优化提供了更清晰的结构基础

对于从旧版本迁移的开发者，虽然需要调整部分实现逻辑，但这种变更使得EF Core的内部实现更加健壮和可维护。建议在实现自定义查询处理器时，充分理解这套新的上下文跟踪机制。