Quem é responsável por atributos de "auditoria" da minha aplicação?

Bom dia,

pessoal, antes de mais nada gostaria de dizer que não queria discutir se existe um framework para auditoria, se isolar isso é melhor isso não vem ao caso. A situação é que tenho alguns Entities que precisam persistir informações em atributos por exemplo: usuarioCriacao, dataCriacao, usuarioAlteracao, dataAlteracao. Portanto, independente dessa ser ou não a melhor maneira de fazer uma pequena auditoria, a minha dúvida está em relação a responsabilidade.

Quem exatamente é responsável por “gerar” essas informações? Algumas idéias foram levantadas, algumas obviamente que são estúpidas e outras mais viáveis, mas, em relação a uma “boa modelagem” em termos de quem realmente tem essa responsabilidade é que eu queria algumas idéias de vocês. Algumas idéias apresentadas aqui, sendo que as “ridículas” são só para ilustrar as diversas possibilidades, são:

  • Responsabilidade dos DAOs: meu dao genérico baseado em um instanceof defini qual entidade tem os atributos em questão e preenche os atributos necessários. Não gostei muito pois, o usuario seria recuperado da Sessão e isso faz com que meu DAO seja exclusivo de uma aplicação Web.

-Responsabilidade de uma camada intermediária ou do controller: sempre que alterar um atributo também deve-se atualizar os atributos de log. (ridículo… pelo menos pra mim)

  • Responsabilidade dos Entities: cada método set realiza a atualização das informações em questão. Também achei péssimo pois espalha muito código pelos Entities prejudicamendo uma futura mudança.

  • Responsabilidade de classes “auxiliares”: por exemplo, como eu uso EJB3, eu poderia utilizar Interceptors para fazer isso (Atualmente o mais forte candidato), ou então, usando @PrePersist, @PreUpdate, do JPA que é a forma que está implementada atualmente mas não está funcional pois esses métodos tem sido executados várias vezes em uma única ação o que acaba zerando algumas informações. Fiz de tudo para descobrir se o problema era os Cascades do JPA ou o Framework Faces mas não consegui descobrir.

Portanto como teremos que alterar, a discussão de “responsabilidades” veio a tona.

obrigado.

Depende do que vc quer auditar e em que camada está.

No caso de persistencia com EJB já trabalhei com algumas auditorias “caseiras”, mas o mais completo que trabalhei foi com Interceptors, com suas tags de @PrePersist, @PreUpdate, etc. Para o que ele dispõe a fazer ele faz.

Tive uma outra necessidade de auditoria que foi captar acesso a funcionalidades de uma aplicação JSF. A aplicação tem poucas chamadas a funcionalidades, dentre 15 a 20. Fizemos uma entidade LOG com atributos que queriamos captar e na chamada de cada ação, chamamos nosso log. Foi uma implementação “caseira” mas para nós foi bem eficiente.