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

Question

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

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

Answer 1

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

Answer 2

[EDIT]

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

---

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

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

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

Answer 3

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

ayende.com / Блог / Архив / 2009/04/29 / NHibernate-ipreupdateeventlistener усилитель-ipreinserteventlistener.aspx

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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