История моментальных снимков с Entity Framework

Посмотрим. У вас есть требование взять граф объектов и сериализовать его в базу данных в формате, который позволит вам материализовать его позже. Я думаю, что есть инструменты, которые делают именно это. Один из них, как мне кажется, это Entity Framework.

То, что вы хотите сделать, это очень распространенная вещь. Рассмотрим вики-движок. Вики должна иметь обзорную версию, которую все видят, а также предыдущие версии каждого документа. Вики также должна иметь возможность отображать предыдущую версию точно так же, как отображается подсказка. Поэтому для них обоих следует использовать один и тот же формат хранения.

Я бы предложил разрешить управление версиями всех типов сущностей. Когда вы редактируете тип объекта, вы редактируете ревизию подсказки и сохраняете предыдущую ревизию, содержащую предыдущие значения. (Причина, по которой вы редактируете редакцию подсказки вместо вставки новой подсказки, заключается в том, что другие объекты, которые в настоящее время не материализованы в ObjectContext, могут содержать ссылки на подсказку, которые вы хотели бы сохранить как ссылки на подсказку, а не ссылки на задняя ревизия)

При необходимости вы можете разбить свои таблицы SQL Server таким образом, чтобы старые версии хранились в другой файловой группе. Это позволит вам делать резервные копии последних и предыдущих версий отдельно.

Сначала вам нужно добавить набор свойств к вашим таблицам:

• Версия - время последней модификации (также может быть автоинкрементный счетчик вместо времени).
• LastModifiedBy - ссылка на пользователя, сделавшего последнее изменение (если вы его сохранили).

Тогда у вас есть несколько вариантов, как сохранить историю версий. Ты сможешь

1. Создайте новую таблицу для каждой из основных таблиц, для которых вы хотите сохранить историю. Эти таблицы истории будут иметь все те же поля, что и основная таблица, но первичные и внешние ключи не будут применяться. Для каждого внешнего ключа также сохраните версию записи, на которую ссылаются, на момент создания версии.

2. ИЛИ вы можете сериализовать все, что интересно о вашей сущности, и хранить все эти сериализованные большие двоичные объекты для всех сущностей, которые вы хотите версионировать, в одной глобальной таблице истории (лично я предпочитаю первый подход).

Как вы заполняете свои таблицы истории? Через триггеры обновления и удаления.

• В триггере обновления для вашей сущности скопируйте все предыдущие значения в таблицу истории. Для каждого внешнего ключа также скопируйте текущую версию объекта, на который делается ссылка.
• В триггере удаления - в основном сделайте то же самое.

Обратите внимание, что все больше и больше современных систем ничего НЕ удаляют. Они просто отмечают вещи как удаленные. Если вы хотите следовать этому шаблону (у которого есть несколько преимуществ) - вместо удаления добавьте флаг IsDeleted к своим объектам (конечно, вам придется везде отфильтровывать удаленные объекты).

Как вы смотрите на свою историю? Просто используйте таблицу истории, так как она имеет все те же свойства, что и основная таблица - не должно быть проблемой. Но при расширении внешних ключей убедитесь, что версия ссылочного объекта совпадает с той, которую вы храните в своей таблице истории. Если это не так, вам нужно перейти в таблицу History этого объекта, на который ссылаются, и получить там значения. Таким образом, у вас всегда будет снимок того, как объект выглядел в ЭТОТ момент, включая все ссылки.

Помимо всего вышеперечисленного - вы также можете восстановить состояние вашей сущности до любой предыдущей версии.

Обратите внимание, что эта реализация, хотя и проста, может занимать некоторое пространство, поскольку она сохраняет моментальный снимок, а не только внесенные изменения. Если вы хотите просто сохранить изменения - в триггере обновления вы можете определить, какие поля были изменены, сериализовать их и сохранить в таблице глобальной истории. Таким образом, вы можете хотя бы показать в пользовательском интерфейсе, что было изменено и кем (хотя у вас могут возникнуть проблемы с возвратом к какой-либо предыдущей версии).

В проекте, который я недавно создал, мы использовали подключение к методу SaveChanges в классе DbContext. Это дало нам доступ к экземпляру класса ChangeTracker. Позвонив ChangeTracker.Entries(), вы получите доступ к списку DbEntityEntry. DbEntityEntry имеет следующие интересные свойства и методы:

• State - объект создается заново, модифицируется или удаляется
• Entity - копия объекта в его нынешнем виде
• CurrentValues - перечисление редактируемых значений
• OriginalValues - перечисление исходных значений

Мы создали набор POCO для наборов изменений и изменений, к которым затем можно было получить доступ через EF. Это позволило нашим пользователям просматривать изменения на уровне поля вместе с датами и ответственными пользователями.

Взгляните на временные таблицы (темпоральные таблицы с системным управлением версиями), если вы используете SQL Server 2016‹ или Azure SQL.

https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15

Из документации:

Функция базы данных, которая предоставляет встроенную поддержку для предоставления информации о данных, хранящихся в таблице, в любой момент времени, а не только данных, которые являются правильными в текущий момент времени. Temporal — это функция базы данных, представленная в ANSI SQL 2011.

Я написал полное руководство, как реализовать его с Entity Framework Core без каких-либо сторонних библиотек здесь:

https://stackoverflow.com/a/64244548/3850405