Question

我最近继承了一个ASP.NET MVC项目。在该项目中，开发人员正在使用async 无处不在。我正在试图评估它是否是一个好主意。具体来说，我正在审查控制器代码。

在控制器中，开发人员编写了如下内容：

public async Task<ActionResult> Index()
{
  return View();
}

这有什么好处而不是传统版本：

public ActionResult Index()
{
  return View();
}

如果在控制器代码中使用async，我可以理解使用await。很多时候，它没有被使用。这种方法有任何理由吗？

Answer 1

没有。在任何地方使用Async都不是一个好主意。

关于缺失await，当Async方法不包含Await运算符时，编译器会发出警告。没有await的Async方法将同步运行，这使得语义不正确。

对于您的具体示例，操作简单且运行时间短，这就是为什么使用Async / Await不会带来任何好处，并且不应该使用它，因此您完全可以使用：

public ActionResult Index()
{
    return View();
}

Async / Await应该用于执行某种IO的控制器方法（例如网络请求，数据库访问等）。如果控制器方法正在进行CPU绑定工作（例如数学计算），那么使用Async / Await实际上会使性能变差，除非您的测量证明我错了。

旧规则适用：测量两次，剪切一次。

Answer 2

如果此方法中没有任何await，则无法制作操作/方法。制作方法async意味着“在盒子下面”（通过编译器）将创建状态机，与纯虚拟版本相比产生一点开销（实际上很小的开销，但如果你有每秒的milion请求可以产生差异; ））。如果你害怕很快就会出现等待（你最好有充分理由“害怕”）并且你有很多代码依赖于这个方法（例如它的抽象类方法/它属于接口）你应该保持返回Task<ActionResult>但不将其标记为异步的方法。例如：

public Task<ActionResult> MyAction() {

    return Task.FromResult<ActionResult>(View());
}

此Task.FromResult<T>方法返回已完成的任务 - 这会阻止编译器创建异步状态机。

回到你的主要问题 - 似乎编写这段代码的人不知道他们在做什么 - 标记方法async并不意味着该方法“异步”工作。

始终在ASP.NET MVC控制器中使用Async

2 个答案: