sql - 无法在我的系统上使用单例中的作用域服务 - 但在 azure 上它可以工作(全部在 net 5 中)

Question

我无法在我的系统上使用单例中的作用域服务 - 但在 azure 上它可以在发布后工作。

在我的 Net 5 服务中，我需要从 azure ServiceBus 监听器写入 SQL-DB。执行此操作，我将“service.AddDbContext”用于数据库，将“service.AddSingleton”用于 ServiceBus 监听器。监听器服务在构造函数中获取 dbContext。由于我总是将服务部署到 azure 来测试它，因此直到我尝试在本地计算机上启动(调试)完全相同的服务时才收到此错误。

Azure 有何不同？我需要立即启动监听器。如果它被限定了范围，它就不会启动。

Answer 1

在开发人员模式下运行时，ASP.NET Core 配置系统 (MS.DI) 会阻止在 Singleton 使用者中(直接或间接)注入(inject)作用域依赖项。它通过其 Scope-Validation feature 来做到这一点。这样做是因为注入(inject)作用域依赖项通常具有状态，并且此类作用域依赖项将由单例保持事件状态。这是一个常见的陷阱，名为 Captive Dependencies .

但是，MS.DI 仅在 Debug模式下执行此检查；可能是因为这项检查需要时间。这意味着，在部署应用程序后，MS.DI 将不会检查此类陷阱，因为在这种情况下，应用程序不再以开发模式运行。

但是，即使没有异常(exception)，并且您认为“发布后就可以工作”，您也应该防止将短期依赖项(例如作用域依赖项)注入(inject)到长期依赖项(单例)中，因为这可能会导致无数难以发现的错误，尤其是 DbContext 实例，因为它们是 not thread-safe and their data get stale very soon .

这意味着，只要有可能，就将消费者(您的监听器)的生命周期降低到 Scoped 或 Transient。然而，如果应用程序只有该监听器的一个实例，则降低生活方式没有任何效果；该实例本质上是单例的，无论其生活方式如何。在这种情况下，监听器应该成为 Composition Root 的一部分。所以它可以直接管理IServiceScope。这样您就可以解析 DbContext 实例 from a new IServiceScope每次调用监听器时。