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

Debugger Membro desde: 05/08/2006 17:00:11 Mensagens: 54 Offline

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.

Notícias, artigos e o maior fórum brasileiro sobre Java