Аудит с помощью spring-data-jdbc? - PullRequest
Новая
       55

Аудит с помощью spring-data-jdbc?

1 голос
/ 08 июля 2019

Я видел ответ на предыдущий вопрос ! , но это не решило мою проблему.

Я проследил код spring-data-jdbc и обнаружил, что до тех пор, пока настраивается событие BeforeSaveEvent и в этом событии устанавливается настраиваемый идентификатор, после выполнения настраиваемого события он продолжает инициировать выполнение RelationalAuditingEventListener # onApplicationEvent на объекте, который был установлен в ID. Решение isNew принято, т.е. New = false.

// IsNewAwareAuditingHandler # markAudited // Запускает метод markModified. entity.isNew(object) ? markCreated(object) : markModified(object);

В чем разница между совокупным корнем и сущностью? Как спроектировать реализацию, которую можно сохранить с помощью @CreatedDate и @CreatedBy при первом сохранении? @LastModifiedDate и @LastModifyBy?

1 Ответ

0 голосов
/ 08 июля 2019

То, что вы описываете, звучит для меня как ошибка. Если вы установили идентификатор в прослушивателе событий, он все равно должен обрабатываться как новый экземпляр. Пожалуйста, отправьте вопрос на https://jira.spring.io/browse/DATAJDBC

Как спроектировать реализацию, которая может быть сохранена с помощью @CreatedDate и @CreatedBy при использовании первого сохранения? @LastModifiedDate и @LastModifyBy?

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

В чем разница между совокупным корнем и сущностью?

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

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

агрегатный корень - это один объект из агрегата. Все взаимодействия с участниками агрегирования должны проходить через корень агрегирования. Это позволяет совокупному корню контролировать согласованность. Например, в приведенном выше примере PurchaseOrder будет агрегатным корнем. Поэтому у вас не будет получателя getItems(), который возвращает коллекцию предметов из жизни. Вместо этого у вас может быть, возможно, addItem(productId, amount) и getItems() вернут копию элементов, поэтому их изменение не повлияет на совокупность.

Определение Мартина Фаулера: https://www.martinfowler.com/bliki/DDD_Aggregate.html

Отличные статьи о агрегатах Вона Вернона:

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf

...