Реализация отслеживания изменений объекта в N-уровневом приложении WCF MVC.

Возможные решения этой проблемы будут во многом зависеть от того, какие изменения вы разрешаете в базе данных, пока пользователь редактирует данные.

Другими словами, после того, как он «покидает» базу данных, блокируется ли она исключительно для пользователя или могут ли другие пользователи или процессы тем временем обновлять ее?

Например, если пользователь может получить данные и просидеть на них пару часов или дней, но база данных продолжает разрешать обновления данных, то вы действительно хотите отслеживать изменения, внесенные пользователем в текущую версию. базу данных, а не изменения, которые пользователь внес в просматриваемые данные.

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

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

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

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

Вы также можете глубоко клонировать объект и передавать его по слоям. Затем, когда пришло время определить, что изменилось, вы снова можете использовать отражение. Однако, в зависимости от размера ваших бизнес-объектов, этот подход может значительно снизить производительность, поскольку полная копия должна быть перемещена по сети и сохранена вместе с исходной записью.

Вы также можете реализовать тот же подход, что и подход «обновления разрешены при редактировании». На мой взгляд, это самое чистое решение, потому что исходные данные не должны перемещаться вместе с отредактированными данными, нет возможности подделать исходные данные, и оно поддерживает множество клиентов без необходимости поддерживать отслеживание изменений в пользовательском интерфейсе. уровень.

Ваш вопрос состоит из двух частей:

1. Как это сделать в MVC:

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

1. Как это сделать в базе данных: это, вероятно, ваш предполагаемый вопрос:

Прежде всего, держитесь подальше от ORM-фреймворков, жизнь слишком сложна.

На последнем этапе операции сохранения у вас должна быть следующая информация:

• Объекты и поля, которые необходимо изменить, и их новые значения.

Вам необходимо отслеживать следующую информацию:

• Какое последнее изменение объекта, который вы собираетесь изменить в базе данных.

Его можно получить из таблицы аудита, и его необходимо сохранить в сеансе (или в объекте, подобном сеансу).

Затем в транзакции нужно сделать следующее:

• Получите последнее изменение объекта (ов) из базы данных.
• Если объекты изменились, отмените операцию и сообщите пользователю о столкновении.
• Если нет, получить текущие значения изменяемых полей.
• Сохраните новые значения.
• Обновите таблицу аудита.

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