IHttpActionResult vs async Task <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)的版本,这些方法提供了轻微的性能提升.但是,使用asyncWeb API 存在一些缺陷,因此除非您了解许多特性,否则坚持使用同步API是明智的.

史蒂芬克利里有很多资料他的博客有关的特质async和await.为了开始,我建议查看不要阻止异步代码.