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

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

[EDIT]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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