返回任务的Web Api方法的缺点

问题描述：

为什么从Web Api方法返回Task<T>的做法不是默认方法，以及在Visual Studio中创建新的Web Api控制器时得到的方法？返回任务的Web Api方法的缺点

这样做有什么缺点吗？

public class MyController : ApiController 
{ 
    public Task<string> Boo() 
    { 
     return Task.Factory.StartNew(() => 
     { 
      return "Boo"; 
     }); 
    } 
}

可能值得注意的是，Task.Factory.StartNew在你想要的意义上并不是真正的异步（即释放线程）。它只是在后台线程上运行，所以没有实际的好处，它只是增加了开销。如果你总是返回任务，你可以使用Task.FromResult，这会让你的方法完全同步。然后，你需要问自己为什么你打算让它更加冗长和不太清楚。 – Frans 2014-09-11 20:34:50

答

当使用异步操作：

您的应用程序必须从外部来源（外部服务，数据库，..）查询数据。 Task与Task使用异步操作是这种情况是可伸缩应用程序的关键，因为您的线程不会阻止等待外部源。
你需要做很多计算绑定操作。由于计算绑定操作发生在CPU上，因此并行化这些操作可以大大提高应用程序的吞吐量，特别是当您的应用程序在多核计算机上运行时。

有了这样说，我们并不总是使用异步：http://msdn.microsoft.com/en-us/magazine/hh456402.aspx

一个典型的例子是，我们并不需要查询从外部数据源的数据，它已经存在：

它实际上可以使开发人员受益，从而避免在特定的一小组用例中使用异步方法，特别是对于将以更细粒度方式访问的库方法。通常情况下，当知道该方法可能实际上能够同步完成时，由于所依赖的数据是已经可用。

与Task异步操作确实有开销：

在设计异步方法，框架开发人员花了很多时间优化掉的对象分配。这是因为分配表示异步方法基础结构中可能发生的最大性能成本之一。分配对象的行为通常非常便宜。分配物品类似于用商品填充您的购物车的，因为它不会花费太多的努力将物品放入购物车;这是当你实际检查出，你需要拉出你的钱包和投资重要的资源。 虽然分配通常很便宜，但当涉及到应用程序的性能时，产生的垃圾收集可能是一个炫目。

答

这样做有什么不利吗？

是的，你让你的代码不易读，性能越来越差，没有很好的理由。我没有看到的优势这样做。

返回任务的Web Api方法的缺点

相关推荐