Ninject InThreadScope 绑定

Question

我有一个 Windows 服务，其中包含一个文件观察程序，当文件到达时会引发事件。当一个事件被引发时，我将使用 Ninject 创建业务层对象，这些对象在它们内部具有对实体框架上下文的引用，该上下文也通过 Ninject 注入。在我的 Web 应用程序中，我总是使用 InRequestScope 作为上下文，这样在一个请求中，所有业务层对象都使用相同的实体框架上下文。在我当前的 Windows 服务场景中，将 Entity Framework 上下文绑定切换到 InThreadScope 绑定就足够了吗？

理论上，当服务中的事件处理程序触发时，它会在某个线程下执行，那么如果另一个文件同时到达，它将在另一个线程下执行。因此这两个事件不会共享一个实体框架上下文，本质上就像网络上的两个不同的 http 请求。

当您查看 Ninject wiki 时，困扰我的一件事是这些线程范围对象的破坏：

.InThreadScope() - 每个线程将创建一个该类型的实例。
.InRequestScope() - 每个 Web 请求将创建一个该类型的实例，并在请求结束时销毁。

基于此，我了解 InRequestScope 对象将在请求结束时（或之后的某个时间点）被销毁（垃圾收集？）。然而，这并没有说明 InThreadScope 对象是如何被销毁的。回到我的示例，当文件观察程序事件处理程序方法完成时，线程消失（回到线程池？）注入的 InThreadScope-d 对象会发生什么？

编辑： 现在有一点很清楚，当使用 InThreadScope() 时，当文件观察程序的处理程序退出时，它不会破坏您的对象。我能够通过在文件夹中删除许多文件来重现这一点，最终我得到了相同的线程 id，这导致了与以前完全相同的实体框架上下文，所以这对于我的应用程序来说绝对是不够的。在这种情况下，5 分钟后进入的文件可能正在使用之前分配给同一线程的陈旧上下文。

Answer 1

线程静态的对象可能存在很长时间，这意味着在某些时候ObjectContext 会变得陈旧并使用旧的（缓存的）值，这将导致难以发现的错误.

我通常创建一个ObjectContext，其范围与我创建数据库事务的范围相同（我什至经常将ObjectContext 包装在数据库事务中，然后将它们一个接一个地处理）。一个（Web）请求可能有多个数据库事务，但通常会有一个“业务事务”，它执行业务逻辑。其他事务可以为日志记录（在业务事务之前、之后，有时在业务事务期间）启动。当您为完整的请求重用ObjectContext 时，您可能会遇到一团糟，因为当业务事务失败时，ObjectContext 可能处于无效状态，这可能会影响重用的操作（例如日志记录）同样的ObjectContext。

对于您的 Windows 服务，我认为文件观察程序引发的每个事件都可能触发新的业务事务。在这种情况下，我会为每个事件创建一个新的 ObjectContext。

长话短说，我不会注入生命周期由您的 IoC 框架管理的 ObjectContext。我会注入一个工厂，允许您的代码创建一个新的ObjectContext 并处理它。我刚刚回答了我们几个关于这个的另一个问题。看看我在that answer.提出的解决方案

祝你好运。