异步存储库和 CancellationToken答案

【问题标题】：Async Repository & CancellationToken异步存储库和 CancellationToken
【发布时间】：2012-11-28 19:22:02
【问题描述】：

我们正在迁移到 .NET 4.5，我正在考虑将异步添加到我的存储库：

interface IRepository<T>
{
    T Find(int id);
    Task<T> FindAsync(int id);
    IEnumerable<T> FindAll();
    Task<IEnumerable<T>> FindAllAsync();
    ...
}

实现可能会调用 DB、WebServices 等。

我的问题是，我应该支持 CancellationToken 吗？

（别担心 - FindAllAsync() 可能是基于 Rx 的:)）

【问题讨论】：

标签： .net-4.5 async-await cancellation cancellation-token

【解决方案1】：

好吧，一定要将async 添加到您的存储库中。我完全赞成async 接管世界。 :)

CancellationToken 支持是另一个问题。如果可能需要它，我通常会提供它或如果底层实现（DB/Web 服务）支持它（在这种情况下，实现是如此简单，我宁愿只提供它）。

请注意，您可以提供不带CancellationToken 的重载，它只调用传递CancellationToken.None 的主要实现。或者，您可以在new CancellationToken() 的接口上给一个默认值，它相当于CancellationToken.None。我过去一直使用默认值方法，但在某些情况下（例如将Action 变量分配给myRepository.FindAllAsync），重载允许方法解析，但默认值不允许。

【讨论】：

【解决方案2】：

我正要问同样的问题。我开始认为答案是“只有当您认为取消是一个重要的场景时”。如果您认为某些存储库会花费很长时间以致用户或基础设施服务想要取消正在进行的查询，那么您应该这样做。我可以想象对于查询，尽管人们会认为大多数更新和插入会很快发生。如果他们不这样做，很可能是由于异常情况导致任务失败（超时？）。

添加对 CancellationToken 的支持将要求所有调用者提供一个，这会产生有害的链接效应。

【讨论】：