异步-等待-我做过头了吗？

Question

public async Task<IHttpActionResult> GetMessages()
{
    var result = await _messageRepository.GetMessagesAsync().ConfigureAwait(false);
    return Ok(result);
}

存储库：

public async Task<List<string>> GetMessagesAsync()    
{
    return await _referralMessageData.GetMessagesAsync().ConfigureAwait(false);
}

数据：

public async Task<List<string>> GetMessagesAsync()
{           
    return await _context.Messages.Select(i => i.Message).ToListAsync().ConfigureAwait(false);
}

Answer 1

如果我们能把async-await放在一个地方，让.NET处理其余部分，那就太好了，但我们不能。那么，是我做过头了还是没那么简单。

如果简单一点就好了。

示例存储库和数据代码中没有太多真正的逻辑（在await之后也没有），因此可以将它们简化为直接返回任务，正如其他评论者所指出的那样。

public async Task<IHttpActionResult> GetMessages()
{
  var result = await _messageRepository.GetMessagesAsync();
  return Ok(result);
}

每种方法都必须使用这种方法。每个使用异步/await的方法都在建立自己的回调。如果不需要回调，那么该方法可以直接返回任务，避免异步/Await。其他异步系统（例如，JavaScript中的promise）也有同样的限制：它们必须始终是异步的。

从概念上讲，可以定义一个系统，其中任何阻塞操作都将自动生成线程。我反对这样一个系统的最重要的论点是，它将具有隐含的重入性。特别是在考虑第三方库更改时，自动生成系统将是不可维护的。在签名中明确API的异步性要好得多（例如，如果它返回task，那么它就是异步的）。

现在，@usr提出了一个很好的观点，也许您根本不需要异步。例如，如果您的实体框架代码正在查询SQL Server的单个实例，那么这几乎肯定是正确的。这是因为Async在ASP.NET上的主要优点是可伸缩性，如果不需要（ASP.NET部分的）可伸缩性，那么就不需要异步。请参阅我的MSDN关于AsyncASP.NET的文章中的“不是灵丹妙药”一节。

当然，相反的论点是，对落后的开发人员的适当反应是培训他们，而不是限制可用的技术。

简言之：

• 执行异步的正确方法是“一路”。在ASP.NET上尤其如此，而且不太可能很快改变。
• 异步是否合适或有用，取决于您和应用程序的场景。