EFには直接「拒否変更」操作はありません。エンティティエントリをChangeTracker
/ObjectStateManager
に移動し、現在の値を変更されたエンティティの元の値で上書きすることができます。また、追加されたエンティティを切り離して、削除されたエンティティを変更しない状態に戻すこともできますが、すべての機能は主に独立した関連(リレーション)の状態を変更しなかった場合にのみ機能します。リレーションを扱う場合は、リレーションシップを元に戻す必要があるため、すべてが複雑になります。そのような場合は、データをリロードする方が簡単です。あなたは、ライブデータの変更を許可し、EFは、そのロジックをする - 私は主な問題は、あなたが実体とどのように動作するかの方法であると思います。この場合、
foreach (var entry in context.ChangeTracker
.Entries<YourEntityType>()
.Where(e => e.State == EntityState.Modified))
{
entry.CurrentValues.SetValues(entry.OriginalValues);
}
:あなたはこれを試すことができDbContext APIの変更を元に戻すために
変更が実行されたときにデータを一貫性を保ちますが、後でそれらの変更が保存されないようにすることができます。この場合、次のいずれかを実行する必要があります
- 破棄は、このロジックは、ライブデータ上で動作し、唯一のEFコンテキストにデータ変更をプッシュしないように(コンテキストを再作成することによって)セパレート
- をデータを変更し、データセット全体をリロード修正が実際に確認されたとき
何かをすると文脈が何かしています。決してそれ自体は忙しくはありません。
コンテキストを再作成することは良い解決策になります。しかし、私は関連するデータの同期に問題がありました。たとえば、私はViewAでCollectionAにCRUDを、ViewBにCOLlectionBにCRUDを持っていたとします。 CollectionBはCollectionAも参照しています。したがって、CollectionAとCollectionBの2つのContextオブジェクトがある場合、ViewAでCollectionAを変更すると、どのようにViewBを同期するのですか? 1つのコンテキストを持つ場合、すべてが同期しているため、実際には2つではなく、1つのインスタンスcollectionAのみで作業しているためです。 「グローバル」コンテキストを再作成すると、混乱が生じます。私は "グローバル"なコンテキストを使って間違いを犯しましたか? – Goran
"Busy"に関しては、非同期マナーでLoadを発行した後に、別のLoadを発行しようとするとどうなりますか?この方法で私はそれが "Busy"かどうかを調べることができたので、新しいLoadをキューに入れることができました。 – Goran
+1ほとんどの人が見逃しているように気付く。関係:状態のエントリコレクションを調べるだけでは取り上げられない変更を追跡することは可能です!=変更されていません。 (EF v6。) – mwardm