EF的DbContext的单例作用域所以我目前正在开发一个使用EntityFramework的ASP.NETMVCweb应用程序，我也在使用Ninject进行依赖注入。所以基本上，目前，这就是我向Ninject注册我的DbContext和服务的方式。kernel.Bind().To().InSingletonScope();kernel.Bind().To().InSingletonScope();kernel.Bind().To().InSingletonScope();kernel.Bind().To().InSingletonScope();我使用InSingletonScope注册它们，这意味着它们只会创建一次并在应用程序的整个生命周期中使用（至少我是这么理解的）。控制器：私人IAccountService_accountService；publicMemberController(IAccountServiceaccountService){_accountService=accountService;但是，我深深地感觉到这个单例范围会在我的web应用程序中引起问题，尤其是对于EntityFramework的上下文，因为它是单例的。我已经面临一个小问题，如果我使用SQLManagementStudio手动更新数据库，我的Web应用程序的实体框架中的数据将不会更新，直到我重新启动应用程序（似乎是EF中的某种缓存机制）。-但是，如果我删除InSingletonScope，我会随机从EF中收到错误消息：多个IEntityChangeTracker实例无法引用实体对象我理解为什么会发生这种情况，因为AccountService可能是使用与RegionService不同的DbContext初始化的。但我不知道如何解决这个问题。我对依赖注入的理解仍然很有限，所以有人可以指教吗？-编辑：我已经尝试将所有注入替换为InRequestScope，但我仍然有多个InRequestScopeIEntityChangeTracker实例无法引用实体对象，该实体对象试图在我的应用程序小时内从另一个服务插入具有相关对象（外键）的新实体.这意味着他们仍在使用不同的DbContext，发生了什么事？！最终编辑：好的，我发现了问题，这是我的缓存机制缓存了以前的请求，导致所有后续请求的关系问题。单身范围对您的上下文来说是一个非常糟糕的主意。请求范围是您应该使用的范围，因为它实际上是请求生命周期中的单例。至于为什么在使用请求范围时会出现错误，我不能肯定地说。假设您正在使用的实体都来自相同的上下文类型，并且您在需要的任何地方都正确地注入了上下文，那么上下文实例永远不应超过一个。编辑重新阅读您的问题后，听起来您的服务实际上是在其构造函数中初始化上下文。如果是这样，那是你的问题。您的上下文应该注入到您的服务中，即：publicclassAccountService:IAccountService{protectedreadonlyDbContextcontext;publicAccountService(DbContextcontext){this.context=context;}...}然后，Ninject将正确地创建任何服务注入请求范围的MyApplicationContext实例。我最终通过使用InRequestScope而不是InSingletonScope解决了这个问题。由于我在服务层上现有的缓存机制，最初我在更改为InRequestScope后仍然面临同样的问题。因此所有后续请求都使用最初缓存的实体对象，这就是我从EF获得多个实例错误的原因。-如果您在更改为InRequestScope后仍然面临MultipleinstancesofIEntityChangeTrackercannotrefertoentityobjects错误，请确保您的实体未以某种方式缓存或存储以用于后续HTTP请求。Dan，当你的整个应用程序只有一个DBContext时，你就会产生瓶颈。在幕后，实体框架将相当有效地处理您需要的对象数量。如果深入到内部，接触数据库的实际对象会做同样的事情。所以试图通过制作单例来优化实际上会产生一个非常大的问题。以上就是C#学习教程：EF的DbContext单例范围分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
