C# 仓储方法如何兼顾异步查询与 IEnumerable 抽象？

2026-11-04数据阿明

现有写法兼顾了异步查询和接口抽象。List<Patient> 实现了 IEnumerable<Patient>，仓储内部创建 List，再通过 IEnumerable<Patient> 返回，是正常的接口用法。

为什么 ToListAsync 不会破坏抽象？

示例中的 Where() 构建查询，ToListAsync() 异步执行查询，将结果加载到内存中的 List<Patient>。方法对外声明的返回类型仍然是 Task<IEnumerable<Patient>>。

这里涉及两个方面：

内部实现：用什么具体类型保存查询结果。
对外契约：调用方可以依赖哪些操作。

仓储可以在内部使用具体类型。service 层得到的是声明为 IEnumerable<Patient> 的结果，可以枚举，但不能直接依赖 List 特有的 Add()、Remove() 等方法。

IEnumerable<T> 也没有承诺延迟执行、流式读取或不使用 List。因此，仓储在内部完成查询并返回列表，符合这个接口的契约。

保留当前返回类型即可

当前方法可以写成：

public async Task<IEnumerable<Patient>> GetWaitingPatientsAsync()
{
    return await _context.Patients
        .AsNoTracking()
        .Where(x => x.Status == PatientStatus.Waiting)
        .ToListAsync();
}

service 层这样调用：

IEnumerable<Patient> patients =
    await repository.GetWaitingPatientsAsync();

foreach (Patient patient in patients)
{
    // 处理查询结果
}

数据库查询在 ToListAsync() 中异步执行。await 完成后，结果已经加载到内存，后续 foreach 会同步遍历这个内存集合。

为什么不能直接返回 ToListAsync 的结果？

如果保持方法签名不变，不能简单删除 async 和 await，改成下面这样：

public Task<IEnumerable<Patient>> GetWaitingPatientsAsync()
{
    // 无法直接转换返回类型
    return _context.Patients
        .AsNoTracking()
        .Where(x => x.Status == PatientStatus.Waiting)
        .ToListAsync();
}

ToListAsync() 返回的是 Task<List<Patient>>。虽然 List<Patient> 可以转换为 IEnumerable<Patient>，但 Task<List<Patient>> 不能直接转换为 Task<IEnumerable<Patient>>，因为 Task<T> 不支持这种协变转换。

原来的 return await 会先等待任务得到 List<Patient>，再将结果作为 IEnumerable<Patient> 返回。因此，这里的 async 和 await 有实际作用。

Where 返回的查询为什么不能直接 await？

Where() 在这里返回描述查询的 IQueryable<Patient>，它本身不是可直接等待的异步操作。构建查询时，数据库访问还没有执行。

要取得结果，还需要使用支持异步执行的终结操作。当前需求是获取全部匹配记录，使用 ToListAsync() 是合理的。如果需要判断记录是否存在或获取单条记录，则应根据业务语义选择相应的异步操作。

await 不仅能等待 Task<T>，也可以用于符合 awaitable 模式的对象。不过，普通的 IQueryable<T> 不会因此自动变得可以等待。

返回类型应该表达什么？

如果调用方只需要遍历患者，保留 Task<IEnumerable<Patient>> 就足够了。如果调用方需要明确依赖集合数量和索引访问，可以考虑 Task<IReadOnlyList<Patient>>，内部仍然可以使用 ToListAsync()。

IEnumerable<T> 不保证底层集合不可修改，IReadOnlyList<T> 也不代表元素对象不可变。接口约束的是通过该接口能够执行的操作。

如果需要逐条异步读取，避免先加载全部结果，则需要另外评估 IAsyncEnumerable<Patient>。这取决于所用框架和查询提供程序是否支持，还需要确保枚举期间数据库上下文保持可用。原问题没有提出流式读取需求，现有实现无需因此调整。