如果我调用DbContext.Dispose而不调用DbContext.SaveChanges会怎么样?
我正在寻找回滚实体更改的方法。我遇到了this answer,它显示了如何设置实体状态,但我想知道如果我简单地处理我的dbContext
实例而不调用dbContext.SaveChanges()
或操纵实体状态会发生什么。如果我调用DbContext.Dispose而不调用DbContext.SaveChanges会怎么样?
我写的这样做的代码绝对有效,但我是否会因为拒绝以这种方式进行更改而让任何事情处于不稳定状态?
如果我只是不调用dbContext.SaveChanges处置我的DbContext实例会发生什么()或操纵实体状态
没有。先前连接到现在配置的DbContext
实例的实例将继续存在,因为任何常规实例都会假设这些实例在某处被某种东西处理。如果没有内存将被释放,并最终垃圾收集为任何其他正常的事情,如果没有处理它。内存中的实体状态保持不变,内存中的任何内容都不会自动恢复。数据库存储也保持“原样”,这意味着不存在从DbContext到数据存储区的调用。
我是留下任何处于不稳定的状态,通过拒绝改变这样
没有,至少在数据存储中。在内存中很难说,它取决于代码的遗漏位置以及依赖关系对修改的依赖。让我们假设它是一个无状态的asp.net应用程序,也许请求只是结束,在这种情况下,下面的任何请求都不应该不稳定,因为它们应该从数据存储中检索需要的东西。
如果它的更长时间像Windows应用程序一样生活,那么您可能必须手动确保先前正在跟踪的实例的任何指针/句柄要么使用现在恢复的内存状态进行更新,要么释放这些指针。
就任何新的DbContext实例而言,它们都是相互独立运行的,所以它们之间没有延续。新的DbContext不知道被跟踪的状态或其他任何DbContext实例所跟踪的状态。
调用Dispose()
类实现IDisposable
的方法意味着你告诉图书馆“我已经完成了这个对象,我将不再使用它,你可以根据需要清理。”这不是特定于实体框架。
对于大多数类而言,尝试在调用Dispose()
后继续使用该对象将会失败,有时会有明确的异常提醒您该问题,有时会由于受损对象状态导致内部异常。您不应该假设实体框架是一个例外:在调用dbContext.Dispose()
之后,您不应再使用dbContext
所引用的上下文。
然而,没有什么从创建一个新背景随即停止你:
dbContext.Dispose();
dbContext = new DbContext();
这种新形势下绝对不会有你的旧背景下所做的任何未保存的更改回忆。有很多这种方法最实用的好例子。
没有什么会处于不稳定的状态,所以不用担心。如果您在处置后尝试调用上下文,您将获得ObjectDisposedException
,否则如果您不再需要它,则处置它是合法的。
这是实际解决我的问题的唯一答案。它不是解释处置是如何工作的,而是关注DbContext本身内的实体。无论如何,你说的是有道理的。上下文中的实体将像任何其他对象一样,只要没有引用它们就会被GC'd存在。如果我不调用'.SaveChanges()',则更改不会被推送到数据库。我很可能会很快将其标记为答案 – oscilatingcretin