什么时候应该在 .net 核心 API 中使用 Scoped？答案

【问题标题】：When should you use Scoped in a .netcore API?什么时候应该在 .net 核心 API 中使用 Scoped？
【发布时间】：2018-08-22 04:03:39
【问题描述】：

当 webapi 处理一个请求时，它使用AsyncLocal- 意思是，容器中的所有单例都隐式地作用于请求。

您会在什么情况下注册 Scoped 服务？

【问题讨论】：

你是从哪里想到的容器中的所有单例都隐式地作用于请求？
因为AsyncLocal的定义。单例的生命周期应该从第一次获取开始，并在应用程序结束时结束——除非我误解了 .netcore 对singleton 的定义。但是由于容器上下文是在AsyncLocal 的范围内创建的（因此是请求的异步线程流），所以我认为一开始就是scoped。现在 scoped 作为选项对 .netcore api 没有意义。

标签： asp.net-core dependency-injection inversion-of-control asp.net-core-2.0

【解决方案1】：

我的理解是，当使用异步等待时，AsyncLocal 提供了一种解决线程静态变量“问题”的方法。在异步等待场景中，代码执行可能会在与开始时不同的线程上结束，因此结束代码可能超出请求中代码之前设置的线程静态变量的范围。此类问题的解决方案（据我所知）是使用 AsyncLocal var 而不是线程静态 var。

这与范围服务完全不同。范围服务的目标是在请求期间使用来自 DI 容器的相同对象。确实，这必须处理异步等待场景，但它也可以处理更简单的情况，即服务被注入到多个方法中，并且您希望在同一请求期间使用相同的对象。

AsyncLocal 和作用域服务这两个概念确实有很大不同。这有帮助吗？

【讨论】：