Response.WriteAsync和返回字符串之间的区别是什么

Question

嗨,如果有人能向我解释这两种从控制器返回数据的方法之间的区别,我就会徘徊.使用方法优于另一方是否有优势或理由？

我猜测返回的功能只是Response.WriteAsync进一步调用,但我不确定.

使用邮递员这两种方法都返回完全相同的响应,所以我只是对这两个选项感到好奇,是否有理由使用其中一个或仅仅是个人偏好.

在Response.WriteAsync之间:

[HttpGet("Fetch_WriteAsync")]
public async Task Fetch_AsyncWrite()
{
    HttpContext.Response.ContentType = "application/json";
    await HttpContext.Response.WriteAsync(JsonConvert.SerializeObject(new { data = "my_fetched_data" }));
}

然后回来:

[HttpGet("Fetch_Return")]
public async Task<string> Fetch_Return()
{
    HttpContext.Response.ContentType = "application/json";
    return await Task.Factory.StartNew(()=>JsonConvert.SerializeObject(new { data = "my_fetched_data" }));
}

Answer 1

基本上,您的代码在引擎盖下的执行方式存在差异.在第一种情况下,你有这个

await HttpContext.Response
                 .WriteAsync(JsonConvert.SerializeObject(new 
                  { 
                      data = "my_fetched_data" 
                  }));

ASP.NET线程将用于执行您的代码.

而在第二种情况下,你有这个

return await Task.Factory
                 .StartNew(()=>JsonConvert.SerializeObject(new 
                 { 
                     data = "my_fetched_data" 
                 }));

将使用线程池线程.

正如这里所说:

您可以在ASP.NET中以完全相同的方式使用ThreadPool,它可以像您期望的那样工作.问题不在于ThreadPool本身,而在于ASP.NET同时使用它的问题.ASP.NET在设计上是多线程的,它使用ThreadPool来提供映射到ASP.NET ISAPI过滤器的页面和内容.

如果您还使用ThreadPool,则ASP.NET使用的线程较少, 并且在池返回空闲 线程之前请求被保留.对于流量较低的站点,这可能不是问题,但更受欢迎的站点可能会遇到麻烦.低流量站点如果使用ThreadPool很多就会遇到麻烦.

话虽这么说,我会选择第一个解决方案.