Transactional (In-Memory) Edits with Entity Framework

Question

In the olden days of the DataSet (and related objects), the in-memory representations of the data objects--DataRow and DataRowView--supported transactional edits through BeginEdit, EndEdit, and CancelEdit. Having both in place allowed more than simply being able to "undo" changes made to an object and reverting it back to its retrieved (or uninitialized) values; the DataRowView object allowed a developer to begin a single editing operation on a DataRow in any state and undo those changes without undoing other changes that might have been made.

For example,

DataRow retrieved as:

Col1    | Col2
----------------
1         2

DataRow Modified to:

Col1    | Col2
----------------
1         3

BeginEdit called on a DataRowView object for this row.

DataRowView modified to:

Col1    | Col2
----------------
2         3

CancelEdit called on the DataRowView, reverting the values to

Col1    | Col2
----------------
1         3

So the change was undone, but the values present before the edit--even though they were in-memory changes and not the retrieved values--are preserved.

Is there any similar facility in the Entity Framework? I have a sneaking suspicion that the answer is "no", considering that it looks like an Entity uses simple backing variables for column values rather than a "property bag" approach like the DataRow uses (or WPF's DependencyProperty infrastructure uses).

Answer 1

There are two ways to do transactions with the Entity Framework, depending upon the depth of transactional support you need.

1. The "right" way to do it is with a TransactionScope instance. The Entity Framework supports this. The downside of this method is that you are now in a distributed transaction, which has security implications for the connection between your machine and your database server.
2. The "lite" way to do it is with the SaveOptions argument to SaveChanges. This allows you to keep change tracking information around after the call to SaveChanges, and "accept" the changes (save to the DB and dispose change tracking information) later.

Regarding your speculation in the last paragraph of the question: In EF 1, change tracking information was typically stored in the ObjectContext. In EF 4, you will have the option to use so-called "self-tracking" entities or proxies, which behave more in the manner you are expecting. But the default, I think, will still be to behave like EF 1. If you look at the generated C# code for your EDMX file, you will see how the property change notification works.

Answer 2

You can implement IEditableObject on your entities.

See here for an example.