总是在ASP.NET MVC控制器中使用异步

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

在控制器，开发人员写类似下面的东西：

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

是否有任何优势，这代替了传统的版本：

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

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

来源

2014-12-13 user687554

我这个[文章]（http://blog.stevensanderson.com/2010/01/25/measuring-the-performance-of-asynchronous-controllers/）总结了AsyncController所要做的。 – 2014-12-13 15:43:29

不，这是不是一个好主意，到处使用异步。

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

为了您的具体的例子，操作简单和短期运行，这就是为什么使用异步/等待不会带来任何好处，它不应该被使用，因此使用是完全没有：

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

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

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

来源

2014-12-13 15:44:11

如果在此方法中没有任何地方存在await，则没有意义做出行动/方法。制作方法async意味着“在盒子下”（通过编译器）将会创建一个状态机，与纯粹的无效版本相比，开销很小（开销很小，但如果每秒有千万个请求可以产生影响）。如果你害怕可能很快就会有人等待（你最好有“害怕”的理由），并且你有很多代码依赖这个方法（例如它是抽象类方法/它属于接口），你应该保留方法返回Task<ActionResult>，但没有将其标记为异步。例如：

public Task<ActionResult> MyAction() { 

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

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

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

来源

2014-12-13 15:53:50 fex

总是在ASP.NET MVC控制器中使用异步

回答

相关问题