System.Linq.Dynamic.Core 中 SQL Server 日期查询的注意事项

在使用 System.Linq.Dynamic.Core 进行动态 LINQ 查询时，开发人员可能会遇到一个常见的陷阱：当针对 SQL Server 数据库执行包含 DateTime 参数的查询时，可能会抛出 InvalidCastException 异常。

问题现象

当开发人员尝试执行类似以下的动态 LINQ 查询时：

dynamic[] results = dbContext.TestObjects
    .Select(parsingConfig, "@0", args: [DateTime.UtcNow])
    .ToDynamicArray();

在 SQL Server 环境下会抛出 InvalidCastException 异常，提示无法将 System.String 转换为 System.DateTime。然而，同样的代码在 PostgreSQL 或内存数据库中却能正常工作。

根本原因

这个问题的根源在于动态 LINQ 表达式的构造方式。当使用 Select 方法时，如果只提供参数值而没有指定要选择的属性，System.Linq.Dynamic.Core 会尝试将整个参数值作为查询结果返回。

对于 SQL Server 提供程序来说，这种处理方式会导致类型转换问题，因为它期望返回的是实体属性而不是原始参数值。

解决方案

正确的做法是在动态 LINQ 表达式中明确指定要选择的属性。例如：

dynamic[] results = dbContext.TestObjects
    .Select(parsingConfig, "Date = @0", args: [DateTime.UtcNow])
    .ToDynamicArray();

这种写法明确告诉 LINQ 提供程序：

1. 我们要选择 Date 属性
2. 将 Date 属性设置为指定的参数值

最佳实践

1. 始终明确指定属性：在动态 LINQ 查询中，应该始终明确指定要选择的属性或表达式，而不是依赖隐式行为。

2. 数据库提供程序差异：不同数据库提供程序对动态 LINQ 的处理可能有细微差别，SQL Server 在这方面通常比其他数据库更严格。

3. 类型安全：明确指定属性有助于提高代码的可读性和类型安全性，减少运行时错误。

4. 测试覆盖：对于跨数据库的应用，应该针对所有支持的数据库提供程序进行测试，确保查询行为一致。

总结

System.Linq.Dynamic.Core 是一个强大的工具，可以让开发人员在运行时构建灵活的 LINQ 查询。然而，在使用时需要特别注意不同数据库提供程序之间的行为差异，特别是在处理日期时间等复杂类型时。通过遵循明确指定属性的最佳实践，可以避免这类类型转换问题，编写出更健壮的数据库查询代码。