我正在为 Google Cloud API 编写客户端库，它具有相当常见的异步帮助程序重载模式:

• 做一些简短的同步工作来设置请求
• 发出异步请求
• 以简单的方式转换结果

目前我们为此使用异步方法，但是:

• 转换 await 的结果在优先级方面很烦人 - 我们最终需要 (await foo.Bar().ConfigureAwait(false)).TransformToBaz()括号很烦人。使用两个语句提高了可读性，但这意味着我们不能使用表达式主体方法。
• 我们偶尔会忘记 ConfigureAwait(false) - 这在某种程度上可以通过工具解决，但仍然有点难闻

Task<TResult>.ContinueWith 听起来是个好主意，但我读过 Stephen Cleary's blog post建议反对它，理由似乎很合理。我们正在考虑为 Task<T> 添加扩展方法像这样:

电位延伸法

public static async Task<TResult> Convert<TSource, TResult>(
    this Task<TSource> task, Func<TSource, TResult> projection)
{
    var result = await task.ConfigureAwait(false);
    return projection(result);
}

然后我们可以非常简单地从同步方法调用它，例如

public async Task<Bar> BarAsync()
{
    var fooRequest = BuildFooRequest();
    return FooAsync(fooRequest).Convert(foo => new Bar(foo));
}

甚至:

public Task<Bar> BarAsync() =>
    FooAsync(BuildFooRequest()).Convert(foo => new Bar(foo));

它看起来如此简单和有用，以至于我有点惊讶居然没有可用的东西。

作为我使用它来使表达式主体方法起作用的示例，在 Google.Cloud.Translation.V2 中code 我有两种翻译纯文本的方法:一种采用单个字符串，一种采用多个字符串。单字符串版本的三个选项是(在参数方面有所简化):

常规异步方法

public async Task<TranslationResult> TranslateTextAsync(
    string text, string targetLanguage)
{
    GaxPreconditions.CheckNotNull(text, nameof(text));
    var results = await TranslateTextAsync(new[] { text }, targetLanguage).ConfigureAwait(false);
    return results[0];
}

表达式体异步方法

public async Task<TranslationResult> TranslateTextAsync(
    string text, string targetLanguage) =>
    (await TranslateTextAsync(new[] { GaxPreconditions.CheckNotNull(text, nameof(text)) }, targetLanguage)
        .ConfigureAwait(false))[0];

使用 Convert 的 Expression-bodied 同步方法

public Task<TranslationResult> TranslateTextAsync(
    string text, string targetLanguage) =>
    TranslateTextAsync(new[] { GaxPreconditions.CheckNotNull(text, nameof(text)) }, targetLanguage)
        .Convert(results => results[0]);

我个人更喜欢最后一个。

我知道这会改变验证的时间 - 在最后一个例子中，传递一个 null text 的值会立即抛出 ArgumentNullException而通过 null targetLanguage 的值将返回一个错误的任务(因为 TranslateTextAsync 将异步失败)。这是我愿意接受的差异。

在日程安排或性能方面是否存在我应该注意的差异？ (我们仍在构建两个状态机，因为 Convert 方法将创建一个。使用 Task.ContineWith 可以避免这种情况，但会遇到博客文章中提到的所有问题。Convert 方法可能会更改为使用ContinueWith 仔细。)

(我有点想在 CodeReview 上发布这个，但我怀疑答案中的信息除了这是否是一个特别好的主意之外还有更普遍的用处。如果其他人不同意，我很乐意移动它。)

最佳答案

Transforming the result of await ends up being annoying in terms of precedence

我通常更喜欢引入局部变量，但正如您所指出的，这会阻止表达式主体方法。

We occasionally forget ConfigureAwait(false) - this is solvable with tooling to some extent

由于您在图书馆工作并且应该使用ConfigureAwait(false) 在任何地方，使用代码分析器都可能是值得的 ConfigureAwait用法。有一个 ReSharper plugin和一个 VS plugin这样做。不过，我自己还没有尝试过。

Task<TResult>.ContinueWith sounds like a good idea, but I've read Stephen Cleary's blog post recommending against it, and the reasons seem sound.

如果您使用了 ContinueWith ，你必须明确指定 TaskScheduler.Default (这是 ContinueWith 相当于 ConfigureAwait(false) ), 并考虑添加标志，例如 DenyChildAttach . IMO 很难记住如何使用 ContinueWith 比记住要正确 ConfigureAwait(false) .

另一方面，ContinueWith是一种低级的、危险的方法，如果您正确使用它，那么它可以给您带来微小的性能改进。特别是，使用 state参数可以为您节省委托(delegate)分配。这是 TPL 和其他 Microsoft 库通常采用的方法，但在 IMO 看来，它大大降低了大多数库的可维护性。

It seems so simple and useful that I'm slightly surprised there isn't something already available.

Convert你建议的方法有existed informally as Then .斯蒂芬没有这么说，但我认为 the name Then is from the JavaScript world ，其中 promises 是等价的任务(它们是 两者 Futures ).

旁注，Stephen's blog post把这个概念带到一个有趣的 结论。 Convert/Then是 bind for the Future monad , 所以它可以 用于实现 LINQ-over-futures。斯蒂芬图布也有 published code for this (在这一点上相当过时，但很有趣)。

我考虑过几次要添加 Then到我的 AsyncEx 库， 但每次都没有成功，因为它几乎是一样的 正如await .它唯一的好处是通过允许方法链接来解决优先级问题。我假设它不存在于框架中 同样的原因。

也就是说，实现您自己的肯定没有错 Convert方法。这样做会避免括号/额外的地方 变量并允许表达式主体方法。

I'm aware that this changes the timing of the validation

这是我成为 wary of eliding async / await 的原因之一(我的博文有更多原因)。

在这种情况下，我认为无论哪种方式都可以，因为“设置请求的简短同步工作”是先决条件检查，IMO 在哪里并不重要 boneheaded exceptions被抛出(因为无论如何都不应该捕获它们)。

如果“简短的同步工作”更复杂——如果它是可以抛出的东西，或者在一年后有人重构它之后可以合理地抛出——那么我会使用 async/await .您仍然可以使用 Convert避免优先级问题:

public async Task<TranslationResult> TranslateTextAsync(string text, string targetLanguage) =>
  await TranslateTextAsync(SomthingThatCanThrow(text), targetLanguage)
  .Convert(results => results[0])
  .ConfigureAwait(false);

关于c# - Task<T>.Convert<TResult> 扩展方法有用还是有隐患？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43536642/