ASP.NET中的HostingEnvironment.QueueBackgroundWorkItem（）用于小型后台任务

我来了一个很好的小工具，已经在v4.5.2中添加到了ASP.NET中

我正在徘徊它是多么安全以及如何在ASP.NET MVC或Web API场景中有效地利用它。

我知道我总是希望在我的Web应用程序中快速简单地执行任务并忘记任务。例如：

现在通常我只创建一个名为的方法

public async Task SendEmailAsync(string to, string body) { //TODO: send email }

我会像这样使用它：

 public async Task Index() { ... await SendEmailAsync(User.Identity.Username, "Hello"); return View(); }

现在我对此的担忧是，我推迟了用户以便向我们发送电子邮件。这对我来说没什么意义。

所以我首先考虑做的是：

 Task.Run(()=> SendEmailAsync(User.Identity.Username, "Hello"));

但是在阅读这篇文章的时候。在IIS环境中显然不是最好的事情。（我不是100％确定细节）。

所以这就是我遇到的HostingEnvironment.QueueBackgroundWorkItem(x=> SendEmailAsync(User.Identity.Username, "Hello"));

这是一种非常快速简便的方法，可以将发送电子邮件任务卸载到后台工作程序，并更快地为用户View()提供服务。

现在我知道这不适用于运行时间超过90 seconds且不是100％保证执行的任务。

但我的问题是：

HostingEnvironment.QueueBackgroundWorkItem()足以用于：在标准ASP.NET网站中发送电子邮件，推送通知，数据库查询等。

这取决于。

QueueBackgroundWorkItem的主要好处如下，强调我的（源）：

与普通的ThreadPool工作项不同，ASP.NET可以跟踪通过此API注册的工作项当前正在运行的数量，并且ASP.NET运行时将尝试延迟AppDomain关闭，直到这些工作项完成执行。

从本质上讲， QueueBackgroundWorkItem通过在仍有任务运行时尝试不关闭应用程序来帮助您运行可能需要几秒钟的任务。

运行正常的数据库查询或发送推送通知应该是几百毫秒（或几秒）的事情; 既不应该花费很长时间，因此可以在QueueBackgroundWorkItem运行。

但是，无法保证完成任务 – 正如您所说，任务未await编辑。这一切都取决于执行任务的重要性。如果任务必须完成，那么它不适合QueueBackgroundWorkItem 。