Транзакционные (в памяти) правки с Entity Framework

Question

В прежние времена DataSet (и связанных объектов) представления в памяти объектов данных - DataRow и DataRowView - поддерживали транзакционные изменения через BeginEdit, EndEdit и CancelEdit. Наличие обоих позволило больше, чем просто «отменить» изменения, внесенные в объект, и вернуть его обратно к его извлеченным (или неинициализированным) значениям; объект DataRowView позволил разработчику начать одну операцию редактирования на DataRow в любом состоянии и отменить эти изменения, не отменяя других изменений, которые могли быть сделаны.

Например,

DataRow получено как:

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

DataRow Изменено на:

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

BeginEdit вызван объект DataRowView для этой строки.

DataRowView изменено на:

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

CancelEdit вызывается на DataRowView, возвращая значения в

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

Таким образом, изменение было отменено, но значения, представленные перед редактированием - даже если они были изменениями в памяти, а не восстановленными значениями - сохраняются.

Есть ли подобная возможность в Entity Framework? У меня есть скрытое подозрение, что ответ «нет», учитывая, что похоже, что Entity использует простые переменные поддержки для значений столбцов, а не подход «мешка свойств», как используется DataRow (или инфраструктура DependencyProperty WPF). использует).

Answer 1

Вы можете реализовать IEditableObject для своих объектов.

См. здесь для примера.

Answer 2

Существует два способа выполнения транзакций с помощью Entity Framework, в зависимости от необходимой вам глубины поддержки транзакций.

1. «Правильный» способ сделать это - экземпляр TransactionScope . Entity Framework поддерживает это. Недостатком этого метода является то, что вы находитесь в распределенной транзакции, что имеет последствия для безопасности соединения между вашей машиной и сервером базы данных.
2. Облегченный способ сделать это с помощью аргумента SaveOptions для SaveChanges. Это позволяет хранить информацию об отслеживании изменений после вызова SaveChanges и «принимать» изменения (сохранять в БД и удалять информацию об отслеживании изменений) позже.

Относительно ваших предположений в последнем абзаце вопроса: в EF 1 информация об отслеживании изменений обычно хранится в ObjectContext. В EF 4 у вас будет возможность использовать так называемые «самопроверяющиеся» сущности или прокси, которые ведут себя более ожидаемым образом. Но по умолчанию, я думаю, все еще будет вести себя как EF 1. Если вы посмотрите на сгенерированный код C # для вашего файла EDMX, вы увидите, как работает уведомление об изменении свойства.