为什么我需要等待已经等待的呼叫（.NET Core 2.2）

Question

我有返回等待成员视图模型的服务方法。

public async Task<MemberVm> GetMember(Guid id)
{
  Task<Member> output = Context.Members
    .SingleOrDefaultAsync(e => e.Id == id);

  return await output != null
    ? new MemberVm(output)
    : null;
}

由于new MemberVm(output)，这无法编译。相反，计算机要求我做new MemberVm(await output)。如果它是一个简单的 return 语句，我会理解它，但在这种情况下，它在评估条件表达式时已经被等待。对我来说，这似乎是伪代码。

if(await output != null)
  return await-again-but-why new MemberVm(output)
else
  return null;

是我做错了还是只是语言语法的意外和不幸后果？

Answer 1

如果您还没有阅读过async..await 的工作原理，您可能应该更好地推理一下；但是这些关键字的主要作用是触发将您的原始代码自动重写为继续传递样式。

基本上发生的事情是将您的原始代码转换为：

public Task<MemberVm> GetMember(Guid id)
{
    Task<Member> output = Context.Members
        .SingleOrDefaultAsync(e => e.Id == id);
    return output.ContinueWith((Task<Member> awaitedOutput) => 
        awaitedOutput.Result != null ? new MemberVm(output.Result) : null);
}

原始的output 变量保持不变，等待的结果（可以这么说）在可用时传递给延续。由于您没有将其保存到变量中，因此在首次使用后您将无法使用它。 （这是我称为 awaitedOutput 的 lambda 参数，如果您自己不将等待的输出分配给变量，它实际上可能会是 C# 编译器生成的乱码。）

在您的情况下，将等待的值存储在变量中可能是最简单的

public Task<MemberVm> GetMember(Guid id)
{
    Member output = await Context.Members
        .SingleOrDefaultAsync(e => e.Id == id);
    return output != null
        ? new MemberVm(output)
        : null;
}

您也可以直接在await 下的代码中使用output.Result，但这并不是您真正应该做的事情，而且有点容易出错。 （如果您出于某种原因无意中将output 重新分配给了不同的任务。这将导致整个线程变为Wait()，我猜它会冻结。）

---

至关重要的是，说“一个已经在等待的电话”没有任何意义。在后台，等待不是您对呼叫或任务执行的事情；这是对编译器的指令，以获取等待之后的所有代码，将其打包到一个闭包中，将其传递给Task.ContinueWith()，然后立即返回新任务。也就是说：await 本身不会导致等待调用结果，它会导致等待代码注册为回调，以便在结果可用时调用。如果你等待一个结果已经可用的任务，所有的变化就是这个回调将被更快地调用。

实现异步的方式是，在您需要等待调用完成的每个点，控制权都会返回到代码外部的某个事件循环。这个事件循环监视“从外部”到达的东西（例如，一些 I/O 操作完成），并唤醒任何等待这个的延续链。当您多次await 同一个Task 时，所发生的只是它处理了几个这样的回调。

（假设，是的，编译器还可以转换代码，以便在等待之后，原始变量名称引用新值。但是有很多原因我认为它没有以这种方式实现 - a变量更改中间函数在 C# 中是史无前例的，并且会令人困惑；而且总体而言，它似乎更复杂，更难推理。）

---

在这里进行一个有希望的说明性切线：我相信当您在同一 async 函数中两次 await 一个任务时会发生什么：

1. 执行到达第一个等待，一个回调（其中包含创建并传递给ContinueWith()，控制返回到顶层。
2. 一段时间后，调用结果可用，回调最终以结果作为参数调用。
3. 第一个回调执行到第二个等待，创建另一个回调并传递给ContinueWith()
4. 由于结果已经可用，可能会立即调用第二个回调，然后您的函数的其余部分将运行。

如您所见，两次等待同一个任务在事件循环中几乎是无意义的绕道。如果您需要任务的值，只需将其放入变量中即可。根据我的经验，很多时候您最好立即await 调用任何async 函数，并将此语句尽可能靠近使用任务结果的位置。 （因为 await 之后的任何代码在结果可用之前不会运行，即使它没有使用该结果。）例外情况是，如果您有一些代码需要在开始调用之后运行，但在使用结果之前，出于某种原因，您不能在通话开始之前运行。

Answer 2

了解编译器标记是类型问题的问题很重要。 MemberVm 构造函数采用 Member 参数，但您的 output 变量的类型为 Task<Member>。编译器真的不希望您再次等待 Task，但这是从 Task 中提取结果并使类型工作的最常用方法。重写代码的另一种方法是更改​​ output 的类型：

Member output = await Context.Members.SingleOrDefaultAsync(e => e.Id == id);

现在您可以将output 直接传递给MemberVm 构造函数，因为您已经保存了第一个等待的结果。

Answer 3

这里已经有正确的答案，但解释远比必要的复杂。 await 关键字在任务完成之前保持执行和解包任务（即Task<Member> 变成了Member）。但是，您并没有坚持那个展开部分。

第二个output 仍然是Task<Member>。它现在已经完成，但它没有被解包，因为你没有保存它的结果。

Answer 4

它无法编译，因为 output 是 Task，而不是 Member。

这可行：

public async Task<MemberVm> GetMember(Guid id)
{
  Member member = await Context.Members
    .SingleOrDefaultAsync(e => e.Id == id);

  return member != null
    ? new MemberVm(member)
    : null;
}

这不是：

Task<Member> output = Context.Members
                             .SingleOrDefaultAsync(e => e.Id == id);

return await output != null // <= "await output" is null or a Member instance
    ? new MemberVm(output)  // "output" is always a Task<Member>
    : null;

通过写await output“输出”本身不会被等待的结果所取代。它仍然是对您在上面创建的任务的相同引用。

---

无关：我不建议返回 null。我想我会让MemberVM 处理使用null 进行设置，或者如果这强烈表明应用程序代码或数据库一致性有问题，则抛出异常。

Answer 5

这行得通吗？

MemberVm 的构造函数是什么样的？

public async Task<MemberVm> GetMember(Guid id)
{
  var output = await Context.Members
    .SingleOrDefaultAsync(e => e.Id == id);

  if (output == null)
     return null;

  return new MemberVm(output);
}

MemberVm 的构造函数似乎没有在其构造函数中使用 Task 参数（尽管没有看到代码，我无法确定）。相反，我认为构造函数只需要一个常规的 MemberVm 参数，因此通过评估 Context.Members... 在其他任何事情之前调用，应该有助于解决你正在发生的事情。如果没有，请告诉我，我们会解决的。