IHttpActionResult 与异步任务<IHttpActionResult>

Question

我见过的大多数 Web API 2.0 方法都返回 IHttpActionResult，它被定义为“定义异步创建 System.Net.Http.HttpResponseMessage 的命令”的接口。

当一个方法返回 async Task<IHttpActionResult> 时发生了什么，我有点困惑。

您为什么要使用其中一个而不是另一个？或者这些功能是否相同 - IHttpActionResult 不是已经异步了吗？

Answer 1

您的操作可能会返回一个IHttpActionResult，它在框架调用其ExecuteAsync 时异步执行该操作。

但是，如果您必须在创建和返回结果之前先进行一些其他异步调用，那么您将不得不将签名更改为async Task<IHttpActionResult>。就是这样。

如果您的控制器操作代码不使用await，那么您可以切换回更简单的签名。但是，您返回的结果仍然是异步的。

需要明确的是，在这两种情况下，您都在使用异步代码。

性能优势在于 - 如果对最深级别的所有调用都是异步的 - 在磁盘或网络 I/O 期间不会阻塞 Web 服务器线程，您的服务器可以用更少的资源处理更多请求。

在对任务调用 Wait 或 Result 或在 ASP.NET 代码中自己创建任务之前请仔细考虑。

为 Web 服务器代码手动编码、故意多线程或并行性的两个正当理由是：

• 当它接收最少的流量但执行计算工作时，每隔一段时间就会调用一次以对数据运行计算，并且您希望使用所有 16 个内核。
• 当同时调用 >1 个数据库分片或 >1 个其他服务时，您需要预先为每个分片查询创建一个任务并等待它们。

Answer 2

使用IHttpActionResult 和async Task<IHttpActionResult> 的区别在于您的任何代码是否使用async 和await 功能。许多库（如 Entity Framework）提供了async 版本的方法（例如SaveChangesAsync），可以稍微提高性能。但是，将async 与 Web API 结合使用存在缺陷，因此除非您了解许多特性，否则最好坚持使用同步 API。

Steven Cleary 在his blog 上有很多关于async 和await 特质的信息。要开始，我建议查看Don't block on async code。