MVC 中的返回 ViewAsync 是一个优势吗？为什么它不存在？

Question

我希望这仍然是主题。在这篇文章中，我看到了如何创建await ViewAsync()： Returning a view with async keyword

所以我的考虑是：好吧，我想让我的应用程序使用多线程，让我们创建一个包含ViewAsync 的方法的BaseController：

只是其中的一部分：

public class BaseController : Controller
{
    [NonAction]
    public virtual async Task<ViewResult> ViewAsync()
    {
        return await Task.Run(() => this.View(null));
    }

    [NonAction]
    public virtual async Task<ViewResult> ViewAsync(string viewName)
    {
        return await Task.Run(() => this.View(viewName, this.ViewData.Model));
    }

    // the other implementations....
}

现在我总是可以在继承类中这样调用：

[HttpGet]
public async Task<IActionResult> DoSomething()
{
    // maybe we need to do something here, maybe not

    return await ViewAsync(new DoSomethingObject());
}

恕我直言，我的优势/目标是性能，因为我现在总是可以使用多线程。

我的考虑是否正确？ 在帖子中，对答案的评论以I wouldn't do this 开头。但是投票/cmets/答案并不多。这种实施的风险或缺点在哪里？也许，为什么Microsoft.AspNetCore.Mvc.Controller 不附带ViewAsync 方法？

Answer 1

任何网络应用程序都已使用多线程。当一个请求进来时，线程池中的一个线程处理它。您的应用已经同时处理多个请求，而无需您使用 Task.Run。

异步/等待的东西很有用，因此您在等待异步操作完成时不会阻塞线程池中的线程（例如查询数据库）。 在默认线程池上启动新任务Task.Run 几乎没有用处，除非您正在做一些 CPU 密集型工作。假设您有一个端点，可以在每个请求上计算最多 n 的质数，在这种情况下，您可以在默认线程池上委派一个新任务，该任务返回质数，并有一个将它们呈现为某些 html 的视图。

渲染视图没有任何异步，因此不需要 ViewAsync。为视图准备数据可能是异步的，但渲染不是。此外，ViewAsync 可能会使模板语法过于复杂。