EF Core 9 中 DbFunction 参数翻译机制的重要变更解析

背景介绍

在 EF Core 8 及之前版本中，当开发者使用 EF.Constant() 方法包装变量作为数据库函数参数时，该参数在翻译阶段会被视为 SqlConstantExpression。这种设计允许数据库提供程序在翻译阶段直接访问常量值，这对于某些需要将字符串值转换为特定格式（如数学矩阵）的数据库函数特别有用。

EF Core 9 的行为变化

EF Core 9 RC2 版本中，这一行为发生了重要变化。现在，当变量通过 EF.Constant() 包装时，在翻译阶段会被视为 SqlParameterExpression，而常量值的评估被推迟到翻译管道的后期阶段。

这种变化带来了以下影响：

1. 数据库提供程序在翻译阶段无法直接获取参数的实际值
2. 需要特殊处理常量参数的数据库函数可能无法按预期工作
3. 开发者需要调整对 EF.Constant() 行为的预期

变更的技术原因

EF Core 团队对这一变更的解释是基于查询管道持续优化的需要：

1. 缓存效率提升：在早期版本中，EF.Constant 节点在管道早期创建，导致缓存命中率低下，因为即使最终结果相同，节点也总是不同
2. 缓存膨胀问题：这种设计会导致缓存不必要地膨胀
3. 统一节点表示：在 EF Core 9 中，节点在翻译管道早期被统一表示为参数，只有在最后阶段才替换为常量

对开发者的影响和建议

1. 兼容性考虑：如果代码依赖于早期评估行为，需要进行调整
2. 替代方案：对于确实需要早期常量评估的场景，可以考虑直接使用 Expression.Constant 构建表达式树
3. 性能权衡：虽然早期常量评估在某些特殊场景下有用，但在绝大多数情况下会降低查询编译效率

最佳实践

1. 对于需要直接使用常量值的数据库函数，考虑重构为查询中的常量部分
2. 避免过度依赖 EF.Constant 的早期评估行为
3. 在升级到 EF Core 9 时，仔细测试所有使用数据库函数的查询

总结

EF Core 9 对 DbFunction 参数翻译机制的变更是查询管道优化的一部分，虽然会影响某些特殊场景的使用，但为大多数查询带来了更好的性能和缓存效率。开发者应当理解这一变更背后的技术考量，并相应调整自己的代码实现。