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

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

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

Ответов (6)

Решение

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

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

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

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

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

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


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

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

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

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

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

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

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

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), вы можете построить все это без всякого знания остальной части вашего кода, что вы проводите аудит.

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

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

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