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

Question

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

[EDIT]

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

---

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

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

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

Answer 4

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

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

Answer 5

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

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

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); 
    } 
} 

Тогда мы могли бы иметь Ревизионную Repository:

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

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

Answer 6

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

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