我一直在阅读很多文章,解释如何设置实体框架,DbContext以便每个HTTP Web请求只使用各种DI框架创建和使用一个.
为什么这首先是一个好主意？使用这种方法有什么好处？在某些情况下这是个好主意吗？在使用DbContext存储库方法调用实例化s 时,您是否可以使用此技术执行某些操作？
我有一个Windows服务,其中包含一个文件监视器,当文件到达时会引发事件.当一个事件被引发时,我将使用Ninject来创建业务层对象,在它们内部引用了一个Entity Framework上下文,该上下文也是通过Ninject注入的.在我的Web应用程序中,我总是使用InRequestScope作为上下文,在一个请求中,所有业务层对象都使用相同的Entity Framework上下文.在我当前的Windows服务方案中,将实体框架上下文绑定切换到InThreadScope绑定是否足够？
理论上,当服务中的事件处理程序触发它在某个线程下执行时,如果另一个文件同时到达,它将在不同的线程下执行.因此,两个事件都不会共享实体框架上下文,实质上就像Web上的两个不同的http请求一样.
当你看Ninject wiki时,困扰我的一件事是破坏这些线程范围的对象:
.InThreadScope() - 每个线程将创建一个类型的实例.
.InRequestScope() - 将根据Web请求创建一个类型的实例,并在请求结束时销毁.
基于此,我了解InRequestScope对象将在请求结束时(或之后的某个时刻)被销毁(垃圾收集？).然而,这并没有说明InThreadScope对象是如何被销毁的.回到我的例子,当文件观察者事件处理程序方法完成时,线程消失(回到线程池？)注入的InThreadScope-d对象会发生什么？
编辑: 现在有一点很清楚,当使用InThreadScope()时,它不会在filewatcher的处理程序退出时销毁你的对象.我能够通过删除文件夹中的许多文件来重现这一点,并最终获得了相同的线程ID,这导致了与之前完全相同的Entity Framework上下文,因此对于我的应用程序来说,这绝对是不够的.在这种情况下,5分钟后出现的文件可能正在使用之前分配给同一线程的陈旧上下文.