Self tracking entity with “check points”

Question

I'm working on a WPF 4/Entity Framework 4 (self tracking entities) application. As a proof of concept, I'm creating a fairly simple UI that's bound to an EF entity.

Our users want to be able to edit the entity, but have the option to accept or reject several sets of changes without saving to the database until later when they are ready. For example, the user can make one set of modifications to the entity and then "accept the changes" (but not save). The next set of modifications made by the user might be "rejected." In this case, the entity would be reverted to the state it was in the last time changes were accepted. The user could then make even more modifications to the entity, but this time, save to the database. The 2nd set of modifications would not be included as they were rejected...

I'm thinking about using the OriginalValues collection, but as the name suggests, it only provides the original values for each field. I'm sure I could write some custom code to Clear the OriginalValues collection when changes are accepted and then revert to the OriginalValues when changes are rejected.

I'm just brainstorming at this point. Has anyone done anything like this? Are there any good examples?

Thanks a bunch!

Answer 1

STEs have no support for this but they are just template so you can implement whatever additional logic you want. Unless you are going to make STEs big reimplementation you should use very simple approach based on GoF Memento pattern. Once user accept changes create deep clone of your entity (serialization followed by deserialization will make a deep copy) and store it somewhere in the memory. If user reject changes just throw away current entity and pick the stored clone instead. STEs should be serializable with DataContractSerializer by default.

Answer 2

I use EF 4 STE the same way. One solution I came up with was to reuse the ChangeTracker in the T4 template. You need a second change tracker instance to track "session" changes. Then, in each session you need to new up the session change tracker instances, and at the end of each session, throw them away. This can be done by not marking the SessionChangeTracker properties as DataMember, and on the deserialization/creatation of each object in the graph, you'll need to instantiate the SessionChangeTracker.

Answer 3

Another solution is to extend the entities with an "IsModified" property using the T4 and a dictionary of property names/values.

You'll have to write a method to get all entities in the graph where modified and then handle the modifications accordingly.