异步/等待和多层Web应用程序

Question

由于一些优化问题，我决定将控制器的操作方法重写为异步方法。 它是一个多层应用程序，因此，我面临一个体系结构问题，我想知道下面将显示的两个方法之间的主要区别是什么。 假设我的同步方法是：

public virtual ActionResult Method()
{
   SomeLogic.LargeOperation();
   return View(...);
}

LargeOpertation做很多事情。 这是伪代码：

public void LargeOpertion() {
   DatabaseManipulations1();
   IndependentWork();
   CallingToWebService1();
   IndependentWork();    
   DatabaseManipulations2();
   IndependentWork();
   CallingToWebService2();
   IndependentWork(); 
}

LargeOperations内部的每个方法内部都有几个方法，依此类推……问题是：我是否需要使它们全部异步并在几乎每个应用程序层中使用await？

public virtual Task<ActionResult> Method()
{
   await SomeLogic.LargeOperation();
   return View(...);
}

public async Task LargeOpertion() {
   await DatabaseManipulations1();
   IndependentWork();
   await CallingToWebService1();
   IndependentWork();    
   await DatabaseManipulations2();
   IndependentWork();
   await CallingToWebService2();
   IndependentWork(); 
}

或者我可以像这样在LargeOpertaion上使用任务：

public virtual Task<ActionResult> Method()
{
   await Task.Run(() => SomeLogic.LargeOperation());
   return View(...);
}

我们还假设IndependentWork（）不太大。

Answer 1

由于一些优化问题，我决定将控制器的操作方法重写为异步方法。

在开始之前，您应该意识到async将为您带来什么，而不会给您带来什么 。

异步操作不会更快地运行。 因此，对数据库的异步调用不会比对数据库的同步调用更快。

await不会尽早返回浏览器。 它所做的只是将当前线程释放回ASP.NET线程池。

因此，每个单独的请求仍会花费相同的总时间（实际上，只是稍长一些 ，但不是可检测的时间）。

async 对可伸缩性的帮助在于可伸缩性，即应用程序使用相同资源处理更多请求的能力。 然而，它不仅可以帮助你的web应用程序的可扩展性-它不能达到神奇到你的数据库，并作出这样的规模。 因此，如果您的可伸缩性瓶颈是数据库而不是ASP.NET（通常是这种情况），那么async将完全无法帮助您。

如果你的数据库后端是可扩展的（例如，NoSQL的，Azure的SQL或数据库集群）， 如果你的ASP.NET应用程序需要扩大规模，那么你就可以受益于async 。

我是否需要使它们全部异步并在几乎每个应用程序层中使用await？

最好的方法是从“叶子”（最低层的方法）开始，然后从那里开始。 在这种情况下，请从数据库交互开始，然后将其首先转换为async 。

但是，绝对不要使用Task.Run或Task.Factory.StartNew 。 相反，请使用真正的异步API，例如EF6中的async支持。