Implementação de Auditoria Trail- Spring AOP vs.Hibernate Interceptor vs DB Gatilho

Question

Eu encontrei algumas linhas de discussão sobre this- mas nada que trouxe uma comparação de todos os três mecanismo sob o mesmo fio.

Então aqui está a minha pergunta ...

Eu preciso auditar DB Alterações de inserção \ updates \ exclusões de objetos de negócios.

Eu posso pensar de três maneiras de fazer isso

1) DB Triggers

2) Hibernate interceptores

3) Spring AOP

(Esta pergunta é específica para uma Primavera \ Hibernate \ RDBMS- Eu acho que isso é neutro para java \ c # ou hibernate \ nhibernate- mas se a sua resposta é dependente de C ++ ou Java ou implementação específica do hibernate- especificar)

Quais são os prós e contras de escolher uma dessas estratégias?

Eu não estou pedindo para a implementação details.-Esta é uma discussão design.

Eu estou esperando que nós podemos fazer isso como uma parte da comunidade wiki

Answer 1

Eu só posso falar sobre disparadores e NHibernate, porque eu não sei enought abou tSpring AOP.

Depende, como sempre, o que é mais importante para você.

DB gatilhos

• são rápidos
• são sempre chamados, mesmo a partir de SQL nativo, scripts, aplicativos externos.
• gravar dados no DB dos quais NH não sabe sobre. Ele vai estar ausente na sessão atual. (O que poderia levar a resultados inesperados)
• geralmente não sabe nada sobre sua sessão. (Digamos: nome de login)

interceptores NHibernate / eventos

• não são DBMS específico.
• permitir o fácil acesso a informações de negócios, como a sessão do usuário, nome da máquina cliente, certos cálculos ou interpretações, localização, etc.
• permitem que você configuração declarativa, como atributos na entidade, que definem se as necessidades da entidade que estar conectado e como.
• permitem que você desligar o registo, este pode ser importante para upgrades, importações, ações especiais que não são acionados pelo usuário.
• permitem uma visão entidade para o modelo de negócio. Você está provavelmente mais perto dos usuários ponto de vista.

Answer 2

Eu entendo isso não é 100% relacionada com a questão, mas ele faz agregar valor com novas opções.

Há mais duas maneiras que você pode auditar o que está acontecendo.

log de transações Leitura: Se banco de dados está em modo de recuperação completa, em seguida, todos os detalhes sobre INSERT, UPDATE, DELETE e instruções DDL são registrados no log de transações.

O problema é que é muito complexo para ler porque não é suportado nativamente e que você precisará de um terceiro leitor de log de transações partido como ApexSQL Log ou SQL Log resgate (o último um é livre, mas só suporta sQL 2000).

A vantagem deste método é que você literalmente não têm que fazer qualquer alteração, exceto para colocar o seu banco de dados em modo de recuperação total.

SQL Server rastreia: Traços irá capturar tudo em arquivos de rastreamento, incluindo instruções select que também podem ser necessários para alguns cenários de conformidade. A desvantagem é que os vestígios são arquivos de texto que precisam ser analisados ??e organizados.

Answer 3

Não consigo pensar em nenhuma boa razão para não usar gatilhos de banco de dados para mudanças de auditoria à base de dados. Inserções, atualizações e exclusões podem potencialmente bater o banco de dados de várias fontes - gatilhos vai pegar todos esses; Hibernate etc. não vai.

Answer 4

I tink quando você considera auditoria, você precisa considerar o que é para. Primeiro, é para gravar havea de quem alterou o quê e o que mudou para que você possa voltar atrás mudanças ruins, você pode identificar problemas com o sistema (podemos ver qual das várias aplicações differnt casued a mudança que ajuda a identificar rapidamente quais um está quebrado) e assim você pode identificar quem fez a alteração. O último pode ser muito crítico quando se trata de detectar fraude. Se você fizer tudo a partir da interface do usuário, você nunca vai ver a fraude cometer usuário que muda os dados no backend para escrever-se um cheque. Se você fizer tudo a partir da interface, provavelmente você tem que ter permissões definidas no nível do tabel, abrindo assim a porta para a fraude, para começar. Se você fizer tudo a partir da interface você não vai saber qual funcionário descontente excluída da tabela inteira do usuário para o valor puro aborrecimento. Se você fazer tudo, desde a extremidade dianteira você não vai saber qual dba incompetente acidentalmente atualizados todos os pedidos de clientes para o mesmo cliente. Não posso apoiar usando nada além de gatilhos para auditoria como você perde uma boa parte da razão pela qual você precisa de auditoria em primeiro lugar.

Answer 5

Usando interceptores Hibernate para executar logs de auditoria está profundamente falho. Estou atordoado pelo número de blogs que recomendam este método sem apontar sua falha mais óbvia - o interceptor tem que usar uma nova transação para gravar a auditoria. Que significa que você pode com êxito salvar a transação principal e tem uma falha no sistema que não consegue registrar a transação de auditoria!

Answer 6

uma questão de idade que i acaso em cima now.There é mais uma opção disponível e que é Envers que está disponível, juntamente com hibernação a partir ver 3.6 em diante ..