FreeSql中使用Like查询时参数化处理的注意事项

在使用FreeSql进行数据库操作时，Where方法中的Like查询参数化处理需要特别注意语法格式。本文将详细解析这一问题，帮助开发者避免常见的陷阱。

问题现象

开发者在FreeSql中尝试使用Like进行模糊查询时，发现以下写法无法返回预期结果：

var list = fsql.Select<object>()
    .AsType(table.Type)
    .Where("adminIds like '%,@a,%'", new { a = 1 })
    .ToList();

虽然生成的SQL语句在替换参数后理论上应该能查询出结果，但实际代码执行却返回空数组。

原因分析

FreeSql处理Where条件中的参数化查询时，会将整个条件表达式解析为SQL语句。在上述写法中，'%,@a,%'被当作一个完整的字符串字面量处理，而不是将@a识别为参数占位符。

正确的参数化写法应该是：

.Where("adminIds like @p1", "%,1,%")

或者使用更明确的参数化方式：

.Where("adminIds like @pattern", new { pattern = "%,1,%" })

解决方案

方案一：直接拼接参数值

var searchValue = "%,1,%";
var list = fsql.Select<object>()
    .AsType(table.Type)
    .Where("adminIds like @pattern", new { pattern = searchValue })
    .ToList();

方案二：使用FreeSql的条件构造器

FreeSql提供了更安全的条件构造方式：

var list = fsql.Select<object>()
    .AsType(table.Type)
    .Where(a => a.As<dynamic>().adminIds.Contains(",1,"))
    .ToList();

方案三：使用原生SQL（不推荐）

var list = fsql.Select<object>()
    .AsType(table.Type)
    .Where("adminIds like '%,1,%'")
    .ToList();

注意：此方案存在SQL注入风险，不建议在生产环境使用。

最佳实践

1. 始终使用参数化查询：避免SQL注入风险
2. 明确参数边界：确保参数占位符不被包含在字符串引号内
3. 优先使用Lambda表达式：FreeSql的Lambda表达式会自动转换为安全的SQL
4. 测试生成的SQL：通过UseMonitorCommand监控实际执行的SQL语句

总结

FreeSql作为一款强大的ORM框架，提供了多种查询方式。在使用Like模糊查询时，开发者需要特别注意参数化查询的语法格式，避免将参数占位符包含在字符串字面量中。正确的参数化方式不仅能保证查询功能正常，还能有效防范SQL注入风险。

对于复杂的模糊查询场景，建议优先考虑使用FreeSql提供的Lambda表达式方式，既能保证类型安全，又能自动生成优化的SQL语句。