Estoy usando NHibernate en un proyecto y necesito hacer una auditoría de datos. Encontré this article en codeproject, que trata sobre la interfaz del intérprete II.Auditoría de datos en NHibernate y SqlServer
¿Cuál es su forma preferida de auditar los datos? ¿Utiliza desencadenadores de base de datos? ¿Utiliza algo similar a lo que se dice en el artículo?
Para NHibernate 2.0, también debe mirar a Event Listeners. Estas son la evolución de la interfaz IInterceptor y las usamos con éxito para auditar.
Prefiero el enfoque de CodeProject que mencionaste.
Un problema con la base de datos activa es que le deja otra opción que utilizar la seguridad integrada, junto con ActiveDirectory como el acceso a 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 se puede anular al crear una cuenta de SQL Server nombrada para todos y cada uno de los usuarios de la aplicación, pero esto no será práctico para aplicaciones web que no sean de intranet ni públicas, por ejemplo.
[EDIT]
posteriores a la liberación NH2.0 busque en los detectores de eventos como se sugiere a continuación. Mi respuesta está desactualizada.
El IInterceptor es la forma recomendada para modificar los datos en nhibernate de una manera no invasiva. También es útil para el descifrado/cifrado de datos sin que el código de su aplicación lo necesite.
disparadores en la base de datos se están moviendo la responsabilidad de la explotación forestal (una preocupación de la aplicación) a la capa de DBMS que une eficazmente 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.
que utilizan interceptores en el código de producción para proporcionar la auditoría en unos grandes sistemas.
Lo que me parece un poco problemático con la solución IInterceptor, es que la fecha 'LastUpdated', por ejemplo, se establece en la fecha que se establece en la estación de trabajo de los clientes, y no es la fecha del servidor de base de datos que se utiliza. –
me gusta el enfoque mencionado interceptor, y utilizar esto en el proyecto Actualmente estoy trabajando.
Sin embargo, una desventaja obvia que merece destacar es que este enfoque sólo cambian los datos de auditoría realizado 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.
Como un enfoque completamente diferente, puede utilizar el patrón de decorador con sus repositorios.
Decir que tengo
public interface IRepository<EntityType> where EntityType:IAuditably
{
public void Save(EntityType entity);
}
Entonces, tendríamos nuestra 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, utilizando un IoC Framework (StructureMap, Castle Windsor, NInject) puedes construirlo todo sin el resto de tu código sabiendo que estaba auditando.
Por supuesto, cómo auditar los elementos de colecciones en cascada es otra cuestión completamente ...
No creo que esta sea la solución correcta a menos que llame a guardar de forma explícita y de alguna manera haya inhabilitado el comportamiento Flush de NH. Es decir. ¡un cambio en una entidad puede persistir incluso sin llamar al método de guardar! – Rashack
Está utilizando session.FlushMode = FlushMode.CommitOnly? –
Si tuviera esto funcionando, terminaría con actualizaciones que ocurren en la base de datos donde no hay cambios utilizando este enfoque. –
Entiendo que esto es una cuestión de edad. 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 para su blog -
hay soluciones alternativas a/dar a cada usuario una cuenta de SQL o el uso de autenticación integrada. Puede hacer que se audite una columna "LastUpdatedByUser" en su tabla y enviarla desde la aplicación siempre que actualice un registro. El activador puede usar el valor de esa columna para completar los registros de auditoría. –