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

Question

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

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

Answer 1

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

Answer 2

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

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

---

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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