Аудит данных в NHibernate и SqlServer

Я использую NHibernate в проекте, и мне нужно провести аудит данных. Я нашел эту статью на codeproject, в котором обсуждается интерфейс IInterceptor.

Какой ваш предпочтительный способ аудита данных? Используете ли вы триггеры базы данных? Используете ли вы что-то похожее на то, что обсуждается в статье?

19.08.2008 09:24:08
6 ОТВЕТОВ
РЕШЕНИЕ

Для NHibernate 2.0 вы также должны посмотреть на Event Listeners . Это развитие интерфейса IInterceptor, и мы успешно используем их для аудита.

14
27.09.2008 02:16:25

Я предпочитаю подход CodeProject, который вы упомянули.

Одна из проблем с триггерами базы данных состоит в том, что у вас не остается иного выбора, кроме как использовать Integrated Security в сочетании с ActiveDirectory в качестве доступа к вашему SQL Server. Причина этого в том, что ваше соединение должно наследовать личность пользователя, который инициировал соединение; если ваше приложение использует именованную учетную запись «sa» или другие учетные записи пользователей, в поле «пользователь» будет отображаться только «sa».

Это можно переопределить, создав именованную учетную запись SQL Server для каждого пользователя приложения, но это будет нецелесообразно, например, для неинтранетных общедоступных веб-приложений.

3
19.08.2008 09:48:50
Существуют обходные пути / альтернативы предоставлению каждому пользователю учетной записи SQL или использованию встроенной аутентификации. Вы можете иметь столбец «LastUpdatedByUser» на проверяемой таблице и отправлять его из приложения при каждом обновлении записи. Триггер может использовать значение этого столбца для заполнения записей аудита.
David Archer 8.04.2009 14:18:46

[РЕДАКТИРОВАТЬ]

После выпуска NH2.0, пожалуйста, посмотрите на прослушиватели событий, как указано ниже. Мой ответ устарел.


IInterceptor - рекомендуемый способ неинвазивного изменения любых данных в nhibernate. Это также полезно для дешифрования / шифрования данных без необходимости знать код вашего приложения.

Триггеры в базе данных переносят ответственность за ведение журнала (проблема приложения) на уровень СУБД, который эффективно связывает ваше решение для ведения журнала с вашей платформой базы данных. Инкапсулируя механизмы аудита в уровне персистентности, вы сохраняете независимость платформы и переносимость кода.

Я использую Interceptors в производственном коде для обеспечения аудита в нескольких больших системах.

5
17.11.2009 11:03:57
Что я нахожу немного проблематичным с решением IInterceptor, так это то, что, например, дата «LastUpdated» установлена ​​на дату, установленную на клиентской рабочей станции, а не на дату использования сервера БД.
Frederik Gheysels 26.05.2009 21:07:04

Мне нравится упомянутый подход Interceptor, и я использую его в проекте, над которым я сейчас работаю.

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

3
20.08.2008 11:18:15

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

Скажи у меня есть

public interface IRepository<EntityType> where EntityType:IAuditably
{ 
    public void Save(EntityType entity);
}

Тогда у нас будет наш NHibernateRepository:

public class NHibernateRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       session.SaveOrUpdate(entity);
   }
}

Тогда у нас может быть ревизионный репозиторий:

public class AuditingRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       entity.LastUser = security.CurrentUser;
       entity.LastUpdate = DateTime.UtcNow;
       innerRepository.Save(entity)
   }
}

Затем, используя IoC Framework (StructureMap, Castle Windsor, NInject), вы можете собрать все это без остальной части вашего кода, зная, что у вас идет аудит.

Конечно, как вы проверяете элементы каскадных коллекций, это еще одна проблема ...

2
17.10.2008 16:50:29
Я не думаю, что это правильное решение, если вы явно не вызываете save и не отключаете поведение сброса NH. Т.е. изменение сущности может сохраняться даже без вызова метода save!
Rashack 17.08.2009 07:27:31
Вы используете session.FlushMode = FlushMode.CommitOnly?
kͩeͣmͮpͥ ͩ 18.08.2009 14:27:01
Если бы у вас это работало, вы бы получили обновления в базе данных, где нет изменений, использующих этот подход.
Alan Christensen 22.03.2012 07:01:41

Я понимаю, что это старый вопрос. Но я хотел бы ответить на это в свете новой системы событий в NH 2.0. Слушатели событий лучше подходят для одитинговых функций, чем перехватчики. Айенде написал отличный пример в своем блоге в прошлом месяце. Вот URL к его сообщению в блоге -

ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx

3
26.05.2009 20:59:37