DbContext和RejectChanges [英] DbContext and RejectChanges

查看:151
本文介绍了DbContext和RejectChanges的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用ObjectContext具有RejectChanges()方法的RIA服务。但是,我现在在桌面应用程序中使用EF 4.4,我找不到该方法。所以,我的问题是:在一个场景中,我允许用户对集合进行批处理操作,我将如何还原所有的更改?我可以重新创建上下文并再次获取数据,但是如果我需要将更改恢复到1-2个实体,那么这个声音非常不必要。



那么,什么是拒绝变更的最佳方式?还有,我们如何知道上下文是否做某事(IsBusy)?

解决方案

EF没有任何直接的拒绝变更操作。您可以通过 ChangeTracker / ObjectStateManager 中的实体条目覆盖修改实体的原始值的当前值。您还可以分离添加的实体并将删除的实体更改为不变,但是只有当您(或EF内部)不更改任何独立关联(关系)的状态时,所有这些实体才会起作用。如果您与关系合作,整个事情可能会变得更加复杂,因为您必须恢复关系 - 在这种情况下,重新加载数据更为简单。为了恢复DbContext API中的更改,您可以尝试以下方式:





  foreach(context.ChangeTracker 
.Entries< YourEntityType>()
.Where(e => e.State == EntityState.Modified))
{
条目.CurrentValues.SetValues(entry.OriginalValues);
}

在这种情况下,我认为主要问题是您如何使用实体 - 允许对实时数据进行更改,而EF会执行其逻辑,以便在执行更改时保持数据一致,但后来您决定不会保存这些更改。在这种情况下,您应该执行以下操作之一:




  • 放弃更改的数据并重新加载整个数据集(通过重新创建上下文)

  • 将此逻辑分离为不适用于实时数据,并且仅在修改确实确认后将数据修改推送到EF上下文



如果你说这样做,某些事情正在做一些事情。它从来不会变得忙碌。


I was working with RIA services where ObjectContext has RejectChanges() method. However, I am now working with EF 4.4 in a desktop application and I cannot find that method. So, my question is: in a scenrario where I allow user to do batch CrUD operations on collection, how would I revert all the changes? I could go with recreating the Context and fetching the data again, but that sound highly unnecessary if I need to revert changes back to 1-2 entities.

So, what is the best way to reject changes? And also, how do we know if the context is doing something (IsBusy)?

解决方案

EF doesn't have any direct "reject changes" operation. You can go through entity entries in ChangeTracker / ObjectStateManager and overwrite current values with original values for modified entities. You can also detach added entities and change deleted entities back to unchanged but that all will mostly work only if you (or EF internally) didn't change the state of any independent association (relation). If you work with relations as well the whole thing can become much more complicated because you must revert relations as well - in such case it is simpler to reload data.

For reverting changes in DbContext API you can try this:

foreach (var entry in context.ChangeTracker
                             .Entries<YourEntityType>()
                             .Where(e => e.State == EntityState.Modified))
{
    entry.CurrentValues.SetValues(entry.OriginalValues);
}

In this case I think the main problem is the way how you work with entities - you allow changes on live data and EF does its logic on behind to keep data consistent when changes are performed but later on you decide that those changes will not be saved. In this case you should do one of following:

  • Discard changed data and reload whole data set (by recreating the context)
  • Separate this logic to not work on live data and push data modification to EF context only when the modification is really confirmed

Context is doing something if you say it to do something. It never becomes busy itself.

这篇关于DbContext和RejectChanges的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆