Auditoria de dados em NHibernate e SqlServer

Question

Estou usando o NHibernate em um projeto e preciso fazer auditoria de dados.eu encontrei Este artigo no codeproject que discute a interface IInterceptor.

Qual é a sua forma preferida de auditar dados?Você usa gatilhos de banco de dados?Você usa algo semelhante ao que é discutido no artigo?

Answer 1

Para o NHibernate 2.0, você também deve olhar Ouvintes de eventos.Estas são a evolução da interface IInterceptor e as utilizamos com sucesso para auditoria.

Answer 2

[EDITAR]

Após o lançamento do NH2.0, consulte os Event Listeners conforme sugerido abaixo.Minha resposta está desatualizada.

---

O IInterceptor é a forma recomendada para modificar quaisquer dados no nhibernate de forma não invasiva.Também é útil para descriptografia/criptografia de dados sem que o código do seu aplicativo precise saber.

Os gatilhos no banco de dados estão transferindo a responsabilidade de registrar (uma preocupação do aplicativo) para a camada DBMS, que vincula efetivamente sua solução de registro à plataforma de banco de dados.Ao encapsular a mecânica de auditoria na camada de persistência, você mantém a independência da plataforma e a transportabilidade do código.

Eu uso Interceptors em código de produção para fornecer auditoria em alguns sistemas grandes.

Answer 3

Eu prefiro a abordagem CodeProject que você mencionou.

Um problema com os gatilhos de banco de dados é que eles não deixam outra escolha a não ser usar a Segurança Integrada juntamente com o ActiveDirectory como acesso ao SQL Server.A razão para isso é que sua conexão deve herdar a identidade do usuário que acionou a conexão;se seu aplicativo usar uma conta nomeada "sa" ou outras contas de usuário, o campo "usuário" refletirá apenas "sa".

Isso pode ser substituído criando uma conta nomeada do SQL Server para cada usuário do aplicativo, mas isso será impraticável para aplicativos Web não intranet e voltados para o público, por exemplo.

Answer 4

Gosto da abordagem do Interceptor mencionada e a uso no projeto em que estou trabalhando atualmente.

No entanto, uma desvantagem óbvia que merece destaque é que esta abordagem auditará apenas as alterações de dados feitas através da sua aplicação.Quaisquer modificações diretas de dados, como scripts SQL ad-hoc que você possa precisar executar de tempos em tempos (isso sempre acontece!) não serão auditadas, a menos que você se lembre de realizar as inserções de tabela de auditoria ao mesmo tempo.

Answer 5

Eu entendo que esta é uma questão antiga.Mas eu gostaria de responder isso à luz do novo Sistema de Eventos do NH 2.0.Os Event Listeners são melhores para funções semelhantes a auditoria do que os Interceptors.Ayende escreveu um ótimo exemplo em seu blog no mês passado.Aqui está o URL da postagem do blog dele -

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

Answer 6

Como uma abordagem totalmente diferente, você poderia usar o padrão decorador com seus repositórios.

Diga que eu tenho

public interface IRepository<EntityType> where EntityType:IAuditably
{ 
    public void Save(EntityType entity);
}

Então, teríamos nosso NHibernateRepository:

public class NHibernateRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       session.SaveOrUpdate(entity);
   }
}

Então poderíamos ter um Repositório de Auditoria:

public class AuditingRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       entity.LastUser = security.CurrentUser;
       entity.LastUpdate = DateTime.UtcNow;
       innerRepository.Save(entity)
   }
}

Então, usando uma estrutura IoC (StructureMap, Castle Windsor, NInject), você poderia construir tudo sem que o restante do seu código soubesse que a auditoria estava em andamento.

Claro, como você audita os elementos das coleções em cascata é outra questão completamente diferente...