FreeSql中WithTempQuery嵌套查询参数传递问题解析

在使用FreeSql进行复杂查询时，开发者经常会遇到需要嵌套子查询的场景。本文将以一个典型问题为例，深入分析WithTempQuery方法中参数传递的机制，帮助开发者理解并避免类似问题。

问题现象

在FreeSql的WithTempQuery方法中嵌套使用Select查询时，外部作用域的变量参数无法正确传递到内部查询中。具体表现为：外部定义的start和end变量在内部Select查询中被识别为新的参数(@exp_4和@exp_5)，但这些参数未被正确赋值。

代码示例分析

以下是一个典型的出现问题的查询示例：

var start = 2023;
var end = 2023;
var res = await Db.Value.Select<MemberCoiHistoryModel>()
    .Where(x => x.Date >= start && x.Date < end && x.Type == CoiType.New && x.State == CoiState.平稳)
    .GroupBy(x => x.MemberId)
    .WithTempQuery(x => new
    {
        MemberId = x.Key,
        ScanSum = Db.Value.Select<MemberActionDayCountModel>()
            .Where(y => y.MemberId == x.Key && y.Date >= start && y.Date < end)
            .Sum(y => y.ScanCode)
    })
    .ToAggregateAsync(x => new
    {
        MemberCount = x.Count(),
        ScanSum = x.Sum(x.Key.ScanSum)
    });

生成的SQL问题

生成的SQL中，外部查询的参数(@exp_0到@exp_3)被正确传递，但内部查询的参数(@exp_4和@exp_5)却未被赋值：

SELECT count(1) as1, sum(a.[ScanSum]) as2
FROM (
    SELECT a.[MemberId], isnull((SELECT sum(y.[ScanCode])
        FROM [scrm_member_action_day_count] y With(NoLock)
        WHERE (y.[MemberId] = a.[MemberId] AND y.[Date] >= @exp_4 AND y.[Date] < @exp_5)), 0) [ScanSum]
    FROM [scrm_member_coi_history] a With(NoLock)
    WHERE (a.[Date] >= @exp_0 AND a.[Date] < @exp_1 AND a.[Type] = @exp_2 AND a.[State] = @exp_3)
    GROUP BY a.[MemberId] ) a

问题根源

这个问题的本质在于FreeSql在处理嵌套查询时，参数作用域的传递机制存在缺陷。当在WithTempQuery内部创建新的Select查询时，外部作用域的参数无法自动传递到内部查询中。

解决方案

针对这个问题，开发者可以采取以下几种解决方案：

1. 使用相同的参数对象：确保内外查询引用的是同一个参数对象，而不是创建新的参数。

2. 显式传递参数：将需要共享的参数提取为类成员变量或静态变量，确保在嵌套查询中能够访问。

3. 重构查询结构：考虑将嵌套查询拆分为多个步骤，避免复杂的嵌套关系。

最佳实践建议

1. 对于复杂的嵌套查询，建议先进行测试，验证参数传递是否正确。

2. 在开发过程中，可以通过打印生成的SQL来检查参数传递情况。

3. 考虑将频繁使用的查询参数封装为DTO或专门的查询对象，提高代码的可维护性。

4. 对于特别复杂的查询，可以考虑使用存储过程或视图来简化应用层代码。

总结

FreeSql作为一款强大的ORM框架，在处理复杂查询时提供了丰富的功能。理解其参数传递机制对于编写高效、可靠的查询至关重要。通过本文的分析，开发者可以更好地掌握WithTempQuery方法的使用技巧，避免在实际开发中遇到类似的参数传递问题。