EF Core如何将NormalizedContains扩展方法改写为可翻译Expression

问题根因 #

EF Core 生成SQL时会解析查询的表达式树，遇到自定义方法调用时，如果没有配置对应的翻译规则，就无法把方法逻辑映射成数据库可执行的SQL，最终抛出翻译失败异常。你当前直接写C#方法体的NormalizedContains只会被编译成IL，EF Core无法反编译解析内部的字符串处理逻辑。

推荐实现方案（兼容后续逻辑扩展） #

这个方案不需要修改你现有查询的写法，同时兼顾内存查询（Linq to Object）和数据库查询的执行逻辑，后续新增字符串预处理规则只需要改两处代码即可。

步骤1：保留扩展方法的内存执行逻辑 #

扩展方法本身的代码不需要大改，用于非数据库查询的场景（比如内存集合过滤）：

public static class StringExtensions
{
    /// <summary>
    /// 归一化字符串包含匹配，内存查询时直接执行该逻辑
    /// </summary>
    public static bool NormalizedContains(this string source, string value)
    {
        if (string.IsNullOrWhiteSpace(source) || string.IsNullOrWhiteSpace(value))
            return false;
        
        // 后续可在此新增其他预处理逻辑：去空格、全角转半角、特殊字符过滤等
        var normalizedSource = source.ToLower();
        var normalizedValue = value.ToLower();
        return normalizedSource.Contains(normalizedValue);
    }
}

步骤2：给EF Core注册该方法的SQL翻译规则 #

在你的DbContext类中重写OnModelCreating方法，添加该方法的翻译映射，告诉EF Core遇到这个方法调用时要生成什么样的SQL逻辑：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 你现有的其他模型配置...

    // 注册NormalizedContains方法的EF翻译规则
    var normalizeContainsMethod = typeof(StringExtensions)
        .GetMethod(
            name: nameof(StringExtensions.NormalizedContains),
            types: new[] { typeof(string), typeof(string) }
        )!;

    modelBuilder.HasDbFunction(normalizeContainsMethod)
        .HasTranslation(argumentExpressions =>
        {
            // 参数顺序和方法定义一致：第一个是调用方法的源字符串，第二个是传入的匹配值
            var sourceCol = argumentExpressions[0];
            var matchValue = argumentExpressions[1];

            // 这里的SQL逻辑和扩展方法的C#逻辑保持一致，后续改逻辑时同步修改这里
            // 1. 源字段转小写
            var loweredSource = new SqlFunctionExpression(
                functionName: "LOWER",
                arguments: new[] { sourceCol },
                nullable: true,
                argumentsPropagateNullability: new[] { true },
                type: typeof(string),
                typeMapping: null);
            // 2. 匹配值转小写
            var loweredValue = new SqlFunctionExpression(
                functionName: "LOWER",
                arguments: new[] { matchValue },
                nullable: true,
                argumentsPropagateNullability: new[] { true },
                type: typeof(string),
                typeMapping: null);
            // 3. 生成LIKE匹配逻辑（自动处理%通配符，比直接翻译Contains更稳妥）
            var likePattern = Expression.Add(
                Expression.Constant("%", typeof(string)),
                Expression.Add(
                    loweredValue,
                    Expression.Constant("%", typeof(string)),
                    typeof(string).GetMethod("Concat", new[] { typeof(string), typeof(string) })
                ),
                typeof(string).GetMethod("Concat", new[] { typeof(string), typeof(string) })
            );

            return new LikeExpression(loweredSource, likePattern, null);
        });
}

轻量替代方案（不想手写SQL表达式时用） #

如果不想手动编写SQL函数表达式，可以实现一个ExpressionVisitor，在EF Core执行查询前，遍历表达式树把所有NormalizedContains方法调用节点，直接替换成内联的s.ToLower().Contains(v.ToLower())表达式，让EF Core用内置的字符串翻译规则生成SQL。
这种方式的好处是后续修改匹配逻辑时，只需要修改替换的表达式片段即可，不需要手动拼接SQL表达式，但需要额外注册EF Core的查询拦截器触发Visitor执行。

注意事项 #

• 不要在NormalizedContains里添加数据库无对应内置函数的逻辑，比如C#专属的正则、编码转换操作，这类逻辑无法被翻译到数据库端执行
• 数据库端的匹配逻辑必须和C#扩展方法的内存逻辑完全一致，避免出现内存查询和数据库查询结果不一致的问题
• 用LIKE实现包含匹配时，EF Core会自动处理参数中的通配符转义，不会出现参数带%、_时匹配错误的问题

内容的提问来源于stack exchange，提问作者Working Pickle