Я использую NHibernate для проекта, и мне нужно провести аудит данных. Я нашел эту статью на codeproject, где обсуждается интерфейс IInterceptor.
Каков ваш предпочтительный способ аудита данных? Используете ли вы триггеры базы данных? Вы используете что-то похожее на то, что обсуждается в статье?
Для NHibernate 2.0 вы также можете посмотреть Слушатели событий. Это эволюция интерфейса IInterceptor, и мы успешно используем их для аудита.
[EDIT]
Опубликуйте выпуск NH2.0, пожалуйста, посмотрите на слушателей событий, как показано ниже. Мой ответ устарел.
IInterceptor - рекомендуемый способ изменения любых данных в nhibernate неинвазивным способом. Он также полезен для дешифрования/шифрования данных без необходимости использования кода приложения.
Триггеры в базе данных переносят ответственность за регистрацию (приложение) на уровень СУБД, который эффективно связывает ваше решение для ведения журнала с вашей платформой базы данных. Инкапсулируя аудиторскую механику на уровне прочности, вы сохраняете независимость платформы и переносимость кода.
Я использую Interceptors в производственном коде для обеспечения аудита в нескольких больших системах.
Я предпочитаю подход CodeProject, о котором вы говорили.
Одна из проблем с триггерами базы данных заключается в том, что у вас нет выбора, кроме как использовать Integrated Security в сочетании с ActiveDirectory в качестве доступа к вашему SQL Server. Причина этого в том, что ваше соединение должно наследовать личность пользователя, вызвавшего соединение; если ваше приложение использует учетную запись "sa" или другие учетные записи пользователя, поле "пользователь" будет отображать только "sa".
Это можно переопределить, создав именованную учетную запись SQL Server для каждого пользователя приложения, но это будет непрактично для веб-приложений, не связанных с интрасети, например, с веб-приложениями.
Мне нравится упомянутый подход Interceptor, и используйте его в проекте, над которым я сейчас работаю.
Однако один очевидный недостаток, заслуживающий внимания, заключается в том, что этот подход будет только проверять изменения данных, сделанные с помощью вашего приложения. Любые прямые модификации данных, такие как специальные SQL-скрипты, которые могут потребоваться время от времени (это всегда происходит!), Не будут проверяться, если вы не забудете одновременно выполнять вставки таблицы аудита.
Я понимаю, что это старый вопрос. Но я хотел бы ответить на это в свете новой системы событий в NH 2.0. Слушатели прослушивания лучше подходят для аудиторских функций, чем для перехватчиков. Айенде написал отличный пример в своем блоге в прошлом месяце. Здесь URL-адрес его сообщения в блоге -
Как совершенно другой подход, вы можете использовать шаблон декоратора с вашими репозиториями.
Скажем, у меня
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), вы можете собрать все это без остальной части вашего кода, зная, что у вас есть аудит.
Конечно, как вы проверяете элементы каскадных коллекций, это еще одна проблема...