Поля аудита для сущностей AppEngine

Ищу предложения по эффективному способу поддержки основных полей аудита для сущностей в AppEngine для Java (через объектизацию). Атрибут @PrePersist выглядит как хороший вариант для различных полей даты (dateCreated, dateModified, dateDeleted), но я также хочу сохранить идентификатор пользователя, который создал, изменил, удалил объект. Лучше всего оставить это на уровне доступа к данным?


java google-app-engine objectify
person Kyle Baley    schedule 31.03.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если вам нужно хранить записи не только с датами, которые вы упомянули, вы, вероятно, захотите создать объект аудита и использовать @Embed для его хранения внутри объектов, которые вы проверяете. Затем используйте @PrePersist для обновления этого объекта. Это даст вам согласованную структуру аудита для всех объектов.

person Rick Mangi    schedule 01.04.2012
comment
Если я использую \@PrePersist, как мне получить идентификатор пользователя? Единственный способ получить к нему доступ — через службу поиска пользователей, которая захватывает его из HttpSession. Является ли обычной практикой внедрение какой-либо службы в объекты домена для получения этой информации? - person Kyle Baley; 01.04.2012
comment
да. Вы можете либо получить его из сеанса, либо прочитать из файла cookie. Это полностью зависит от вашего приложения. Как правило, уровень DAO вашего приложения будет иметь такой метод, как doUpdate(User, Entity) - person Rick Mangi; 01.04.2012
comment
У нас есть уровень DAO, но я не уверен, что мне нравится идея передавать пользователя каждому методу doUpdate. Разве уровень DAO не должен знать, как это сделать? - person Kyle Baley; 08.04.2012
comment
Если вы напишете это таким образом... Но он должен откуда-то получить пользователя, в данном случае это https-сеанс или переменная, которую вы передаете. Вы можете прикрепить сеанс с пользователем к локальному объекту потока и получить его таким образом, если вам нравится, но это зависит от вас, чтобы управлять. - person Rick Mangi; 08.04.2012
comment
Не забывайте, пользователь — это то, что вы изобретаете. Objectify не имеет понятия о пользователе, а objectify 4 даже не имеет объекта dao. Таким образом, если слой дао не должен знать, как это сделать, это действительно ошибочно. - person Rick Mangi; 08.04.2012

arrow_upward
0
arrow_downward

ИМХО @PrePersist это нормальное место для этого.

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

person Peter Knego    schedule 31.03.2012