sql server - una - Auditoría de datos en NHibernate y SqlServer
sql server auditoria a bases de datos (6)
Como enfoque completamente diferente, puede usar el patrón de decorador con sus repositorios.
Digamos que tengo
public interface IRepository<EntityType> where EntityType:IAuditably
{
public void Save(EntityType entity);
}
Entonces, tendríamos nuestro NHibernateRepository:
public class NHibernateRepository<EntityType>:IRepository<EntityType>
{
/*...*/
public void Save ( EntityType entity )
{
session.SaveOrUpdate(entity);
}
}
Entonces podríamos tener un Repositorio de Auditoría:
public class AuditingRepository<EntityType>:IRepository<EntityType>
{
/*...*/
public void Save ( EntityType entity )
{
entity.LastUser = security.CurrentUser;
entity.LastUpdate = DateTime.UtcNow;
innerRepository.Save(entity)
}
}
Luego, usando un Marco de IoC (StructureMap, Castle Windsor, NInject) puedes construirlo todo sin el resto de tu código, sabiendo que tienes una auditoría en marcha.
Por supuesto, cómo auditar los elementos de las colecciones en cascada es otro tema completamente diferente ...
Estoy usando NHibernate en un proyecto y necesito hacer una auditoría de datos. Encontré este artículo en codeproject que analiza la interfaz de IInterceptor.
¿Cuál es su forma preferida de auditar datos? ¿Utiliza desencadenadores de base de datos? ¿Utiliza algo similar a lo que se dice en el artículo?
Prefiero el enfoque de CodeProject que mencionaste.
Un problema con los desencadenantes de la base de datos es que no le deja más remedio que usar Integrated Security junto con ActiveDirectory como acceso a su SQL Server. La razón de esto es que su conexión debe heredar la identidad del usuario que activó la conexión; si su aplicación usa una cuenta llamada "sa" u otras cuentas de usuario, el campo "usuario" solo reflejará "sa".
Esto puede ser anulado al crear una cuenta de SQL Server nombrada para cada usuario de la aplicación, pero esto no será práctico para aplicaciones web que no sean de intranet ni públicas, por ejemplo.
Me gusta el enfoque de Interceptor mencionado, y lo uso en el proyecto en el que estoy trabajando actualmente.
Sin embargo, una desventaja obvia que merece destacarse es que este enfoque solo auditará los cambios de datos realizados a través de su aplicación. Cualquier modificación directa de datos como scripts SQL ad-hoc que pueda necesitar ejecutar de vez en cuando (¡siempre ocurre!) No será auditada, a menos que recuerde realizar las inserciones de la tabla de auditoría al mismo tiempo.
Para NHibernate 2.0, también debe mirar a los oyentes del evento . Estas son la evolución de la interfaz IInterceptor y las usamos con éxito para auditar.
Entiendo que esta es una vieja pregunta. Pero me gustaría responder a esto a la luz del nuevo sistema de eventos en NH 2.0. Los oyentes de eventos son mejores para auditar como funciones que los interceptores. Ayende escribió un gran ejemplo en su blog el mes pasado. Aquí está la URL de su publicación de blog:
[EDITAR]
Publica la publicación NH2.0, mira a los oyentes del evento como se sugiere a continuación. Mi respuesta está desactualizada.
El interferómetro II es la forma recomendada de modificar cualquier dato en nhibernate de forma no invasiva. También es útil para el descifrado / cifrado de datos sin que el código de su aplicación lo necesite.
Los desencadenantes en la base de datos están trasladando la responsabilidad del registro (una preocupación de la aplicación) a la capa DBMS que vincula efectivamente su solución de registro a su plataforma de base de datos. Al encapsular la mecánica de auditoría en la capa de persistencia, conserva la independencia de la plataforma y la transportabilidad del código.
Uso interceptores en el código de producción para proporcionar auditorías en algunos sistemas grandes.