Quartz.Net 作业中使用的 DBContext 的 Ninject 作用域

Question

在执行 Quartz.Net 作业实现期间通过 Ninject 依赖解析器实例化的 DbContext 实现使用的最佳范围是什么？如果我使用线程范围，如果 Quartz 线程池中的同一个线程用于多次执行作业，是否会提供同一个 DbContext 实例？

我想要一个范围，这意味着每次触发作业时我都会获得一个(并且只有一个)新的 DbContext 实例。

Answer 1

是的，我建议不要使用 InThreadScope .当使用线程池线程时，会出现泄漏。

此外，ninject 没有像“QuartzScope”这样的内置功能，因此您必须创建自己的解决方案。让我们从作业的实例化开始。 this stackoverflow answer 涵盖了这些内容更广泛地说，由 the source code of this nuget package .

现在一种可能的解决方案是扩展 JobFactory 以管理 DbContext 的创建。并将其注入(inject)作业及其所有依赖项(作为继承的 ConstructorArgument 参数)。然而，这有两个缺点: 总是创建一个 DBContext (无论工作是否需要)，您需要跟踪DBContext实例，以便您可以 .Dispose()其中IJobFactory.ReturnJob(IJob)方法(例如 Dictionary<IJob, DBContext 或类似方法)。

更简单的方法是使用 .InCallScope (包含在 Ninject.Extensions.NamedScope 中)对于 DbContext捆绑。这将创建一个 DbContext每个 kernel.Get<FooJob>() 的实例.

如果您需要为您的 DbContext 设置不同的范围- 取决于你在哪里使用它们，p.Ex。在 Job 和 ASP.NET MVC 内容中，您可能想查看 Ninject Conditional Self bind to change scope (For Task-scheduler) not working properly?