Управляемый доменом дизайн - логические удаления

Question

Итак, у меня есть хорошая модель предметной области. Хранилища обрабатывают доступ к данным, а что нет. Появились новые требования, которые указывают, что причины должны быть зарегистрированы с удалениями. До сих пор удаление было довольно простым = > Entity.Children.Remove (ребенок). Внутреннего отслеживания изменений не происходило, так как мой инструмент ORM занимался управлением состоянием. Однако я не совсем уверен, как с этим справиться.

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

2) ??????

Answer 1

Хорошо, это звучит безумно, и я собираюсь сделать еще один снимок - даже если меня отшлепают за плохое использование nHibernate. Прежде чем удалять, почему бы вам не выбрать дочерние элементы, которые будут удалены (у вас уже есть правильные идентификаторы?), И выполнить преобразование в любой объект, который вы собираетесь использовать для записи удалений в таблицу. Добавьте причину к сущностям и сохраните их - затем продолжите удаление. Лучшая часть, вы можете использовать общую сущность, то есть " auditInfo " для результата преобразования, и вы можете сделать это в транзакции, чтобы вы могли откатить все, если что-то не получится! Хорошо, может быть, сумасшедший, но творческий, верно?

Answer 2

Не могли бы вы реализовать интерфейс IInterceptor и переопределить функциональность onDelete, чтобы извлечь нужную информацию из сущности и отправить ее в регистратор перед удалением (конечно, используя NHibernate)?

пример

Answer 3

Если удаление является относительно редким для данного конкретного типа объекта, я бы добавил к объекту флаг, чтобы пометить его как логически "удаленный". вместо того, чтобы фактически удалить строку. В этом случае приложение должно обрабатывать сокрытие этих объектов в обычных условиях.

Если это приведет к недопустимому количеству "устаревших" строки - я бы предложил что-то похожее на ответ Уотсона. В зависимости от точных требований, вы, вероятно, могли бы избежать регистрации удаленных данных и дополнительной «причины». поле где-то прямо из приложения. Использование перехватчиков более прозрачно и приятнее с точки зрения аудита, но отдельный журнал удаления (таблица, база данных, файл), вероятно, проще.