Простой способ сохранить основные данные аудита на объектах домена?

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

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

Но как?

Я, конечно, мог бы сделать это из моего DAO, но как обрабатывать объекты, которые сохраняются с помощью каскадного сохранения? Есть ли способ перехватить на них метод persist ()?

Как лучше всего реализовать эту возможность?


person HDave    schedule 07.07.2010    source источник


Ответы (2)


Если вы собираетесь использовать JPA для аудита, вы можете положиться на аннотации обратного вызова PrePersist и PreUpdate. В JPA WikiBook есть один такой пример. В этом случае очень помогает наличие отображаемого суперкласса, в противном случае вы продолжите делать это с помощью "пользовательского" кода пространства.

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

Обновление: рекомендуется выделить функцию аудита в другой класс, отличный от суперкласса модели предметной области. Слушатели событий JPA помогут вам добиться того же. Хороший пример представлен здесь < / а>.

person Vineet Reynolds    schedule 07.07.2010
comment
Чистое добро JPA. Спасибо за совет и ссылку о PrePersist и PreUpdate. Что касается идеи хранения всей аудиторской информации в одной таблице, она кажется потенциальным узким местом для производительности ... нет? - person HDave; 07.07.2010
comment
Хм, это интересный вопрос; ответ будет зависеть от того, что вы храните в одной таблице и как часто это запрашивается. Если вы ожидаете, что пользователи будут запрашивать и просматривать информацию аудита относительно много во время обычного процесса работы, вам может быть лучше проводить аудит каждой сущности отдельно. Однако, если таблица аудита должна быть более или менее таблицей, предназначенной только для SELECT, то это обязательно принесет меньше вреда, поскольку с точки зрения производительности вам нужно беспокоиться только о INSERT. Я думаю, что требуется некоторое планирование мощностей, чтобы предвидеть количество входов в производство. - person Vineet Reynolds; 07.07.2010
comment
В моем конкретном случае большую часть времени будет происходить множество обновлений и запросов к этой информации, поэтому я продолжу хранить ее в той же записи, что и объект. Однако у меня есть несколько мест, где извлечение этой информации было бы большим подспорьем. - person HDave; 07.07.2010

Возможно, вам стоит взглянуть на Hibernate Envers.

person wallenborn    schedule 07.07.2010
comment
Вау - Энверс потрясающий. Как я никогда не слышал об этом раньше? Будем уделять этому серьезное внимание. - person HDave; 07.07.2010