В данный момент разрабатываю систему для Human Resources на ASP.NET. Как платформу использую Web Client Software Factory, для доступа к данным — NHibernate. Появилось требование — реализовать историю изменеий объектов домена. Но не просто кто и когда менял последним запись о сотруднике, а детально, какие поля какого объекта, кем, когда менялись. Много перечитал но к решению так и не пришел.
В каком слое лучше реализовать такой функционал, и как приблизительно должно выглядеть такое решение?
Я выделяю 2 сценария: создание business entity и дальнейшее ее редактирование. Допустим удалять в системе ничего нельзя (информация вечная).
В какой момент лучше делать запись в лог? Фаулер описывал подход когда сами объекты в setter свойствах вызывали Логер. Но это как-то коряво, и не логично — доменным объектам должно быть все равно, есть ли аудит или нет.
Может лучше с помощью какого-то атрибута над свойствами? Но тогда куда передавать сообщение о том что я (свойство) изменилось? Какой шаблон лучше для этого использовать?
Кто-то мне предлагал перед апдейтом сравнивать первоначальное состояние объекта с текущим при помощи рефлексии, и список изменений заносить в лог. Но прохоить по дереву полей объекта каждый раз при обновлении — это наверно долго. Хотелось бы чтобы изменения заносились в какое-то хранилище, типа транзакции, именно в момент изменеий, но вот как именно такое организовать?
Здравствуйте, Alkersan, Вы писали:
A>В каком слое лучше реализовать такой функционал, и как приблизительно должно выглядеть такое решение?
Сейчас модно группировать операции над сущностями в сервисах, а аудит подключать декларативно, задействуя интерсепторы-перехватчики вызовов методов сервисов. См. PostSharp (интерсепторы подключаются на этапе компиляции) или Unity (умеет, например, выполнять перехват виртуальных вызовов)
Здравствуйте, Alkersan, Вы писали:
A>Кто-то мне предлагал перед апдейтом сравнивать первоначальное состояние объекта с текущим при помощи рефлексии, и список изменений заносить в лог. Но прохоить по дереву полей объекта каждый раз при обновлении — это наверно долго. Хотелось бы чтобы изменения заносились в какое-то хранилище, типа транзакции, именно в момент изменеий, но вот как именно такое организовать?
Это в принципе правильный вариант. Незнаю как NHibernate, а из EF можно вытащить список измененных полей объекта. Вероятне всего и в хибернейте есть такая возможность
соответсвенно перед коммитом изменений можно записывать куда-нибудь эти изменения. отслеживать изменения в свойствах категорически не стоит.
Кстати имеет смысл посмотреть в сторону sharepoint, там есть как аудит, так и версионирование записей.
Здравствуйте, gandjustas, Вы писали:
G>Кстати имеет смысл посмотреть в сторону sharepoint, там есть как аудит, так и версионирование записей.
На шерпоинт смотреть не стоит, т.к. система строится как раз для того, чтобы отказаться от шерпоинта
B> Ааудит подключать декларативно, задействуя интерсепторы-перехватчики вызовов методов сервисов
Можно детальнее описать такой подход? Я смотрел быстрый старт PostSharp, они создали там атрибут, который пишет в трейс информацию том какой метод выполняется. Т.е. можно также написать атрибут, который будет вызывать Логер, когда вызывается setter какой-то проперти?
Здравствуйте, Alkersan, Вы писали:
A>выполняется. Т.е. можно также написать атрибут, который будет вызывать Логер, когда вызывается setter какой-то проперти?
Сорри, недочитал. С пропертями сложнее, да и нужно ли на каждый чих вызывать логгер? Ведь изменение свойств сущностей обычно накапливают в модели, а потом производят транзакционное обновление.
B>Изменение свойств сущностей накапливают в модели, а потом производят транзакционное обновление.
Накопление изменений реализовано в NHibernate, он точно реализует шаблон UnitOfWork, но я не знаю как извлечь список измененний в текущей сессии. Может кто-то знает?
K> NIH-синдром? Или есть более веские причины?
Нет, никакого синдрома. Просто, как мне кажется, даже на мощном шерпоинте трудно реализовать весь функционал бизнесс системы. Шерпоинт — это по сути портал с контентом. В этом плане он очень удобен, и как центральный информационный ресурс компании он и используется. Но когда доменная модель со своими приколами — то тут надо писать все руками.
Здравствуйте, Alkersan, Вы писали:
B>>Изменение свойств сущностей накапливают в модели, а потом производят транзакционное обновление.
A>Накопление изменений реализовано в NHibernate, он точно реализует шаблон UnitOfWork, но я не знаю как извлечь список измененний в текущей сессии. Может кто-то знает?
Здравствуйте, Alkersan, Вы писали:
K>> NIH-синдром? Или есть более веские причины? A>Нет, никакого синдрома. Просто, как мне кажется, даже на мощном шерпоинте трудно реализовать весь функционал бизнесс системы. Шерпоинт — это по сути портал с контентом. В этом плане он очень удобен, и как центральный информационный ресурс компании он и используется. Но когда доменная модель со своими приколами — то тут надо писать все руками.
Ну если изначально взялись за "доменную модель", то SP вам будет только мешать. Но не факт что такая модель нужна в HR.
Здравствуйте, Alkersan, Вы писали:
A>В данный момент разрабатываю систему для Human Resources на ASP.NET. Как платформу использую Web Client Software Factory, для доступа к данным — NHibernate. Появилось требование — реализовать историю изменеий объектов домена. Но не просто кто и когда менял последним запись о сотруднике, а детально, какие поля какого объекта, кем, когда менялись. Много перечитал но к решению так и не пришел. A>В каком слое лучше реализовать такой функционал, и как приблизительно должно выглядеть такое решение?
Если вам не нужно потом будет использовать эту накопленную историю как-то хитро в предметной области, то решение такое:
— реализовать в отдельном, отвязанном от логики, facility (history & audit facility, H&aF );
— к NHibernate подключить interceptor'ы (штатная возможность), которые и будут оповещать H&aF об изменении данных.
Если история будет вплетена в домен, то и H&aF нужно размещать тесно с остальной логикой; вероятно, можно обойтись и без перехватчиков уровня ORM.
Здравствуйте, Alkersan, Вы писали:
A>В данный момент разрабатываю систему для Human Resources на ASP.NET. Как платформу использую Web Client Software Factory, для доступа к данным — NHibernate. Появилось требование — реализовать историю изменеий объектов домена. Но не просто кто и когда менял последним запись о сотруднике, а детально, какие поля какого объекта, кем, когда менялись. Много перечитал но к решению так и не пришел. A>В каком слое лучше реализовать такой функционал, и как приблизительно должно выглядеть такое решение?
Здравствуйте. Насколько я понял — вопрос о реализации версионности. По этой ссылке описан очень понятный механизм. В конце есть ссылка на пдфку с более детальным описанием. http://software.intel.com/ru-ru/blogs/2009/03/09/2000727/
Если будут вопросы — обращайся, объясню детали если что
_>вопрос о реализации версионности. По этой ссылке описан очень понятный механизм
В моем случае скорее не версионность, а аудит изменений. Нужен самый простой механизм, когда не нужны откаты. Просто чтобы велся лог какие поля каких доменных объектов были изменены, кем и когда, желательно с возможностью гибкой настройки полей поддающихся аудиту(но это уже не столь важно, возможно в будущих версиях). Есть корневой объект — Сотрудник. В нем есть множество всязанных классов — контакты, телефоны, адреса, отпуска и т.д.
Re[3]: Аудит доменной модели
От:
Аноним
Дата:
02.07.09 19:06
Оценка:
Здравствуйте, Alkersan, Вы писали:
_>>вопрос о реализации версионности. По этой ссылке описан очень понятный механизм
A>В моем случае скорее не версионность, а аудит изменений. Нужен самый простой механизм, когда не нужны откаты. Просто чтобы велся лог какие поля каких доменных объектов были изменены, кем и когда, желательно с возможностью гибкой настройки полей поддающихся аудиту(но это уже не столь важно, возможно в будущих версиях). Есть корневой объект — Сотрудник. В нем есть множество всязанных классов — контакты, телефоны, адреса, отпуска и т.д.
Да-да, именно аудит в данной схеме и описан.
Возможность откатить изменения — это вовсе не главное и имплементация заняла буквально пару строк кода и один юнит-тест
Нашел в офисе такую книгу, пролистал, но ничего по архитектуре регистров не нашел."На примере создания реального прикладного решения показана структура различных объектов системы". Фактически описано программирование мышкой
То, что существуют отличные системы аудита, я знаю. Мне не нужна такая функиональность как в 1С. Вопрос изначально был такой: какой эффективный шаблон стот применять для ведения истории изменеий доменной модели, при использовании NHibernate и слоёной архитектуры веб приложения.
Ну реверс-инжиниринг 1С предприятия, конечно, тоже решение .
