REGISTROS DE LOGS

NOWLIGHTS 06/02/2024 23:49:43
#503009
Alterado em 06/02/2024 23:51:59 Boa noite pessoal, tudo certo?

Estou quebrando a cabeça para encontrar a melhor solução para 'registro de Logs', o que preciso é;

Ex. usuário X editou a agenda Y

Separado por tipo de arquivo (ou tabelas), ex.: AgendaLog.txt, ItemLog.txt ou algo do tipo

Ja pensei em criar tabelas no banco de dados, mas talvez o esforço e complexidade nao seria interessante!?.
Já vi também o uso de NLog/Serilog (acredito que nao me atenderia...)


Essas logs seram exibidas para o cliente para verificar as logs de modificações da genda, serviço... (exemplo, para verificar quem excluiu uma agenda, quem modificou uma agenda e etc..)

Qual a melhor forma de fazer isso?
KERPLUNK 07/02/2024 06:51:31
#503010 Resposta escolhida
Vai depender muito de como você grava os seus dados.
Da última vez que fazia isso, eu tinha uma abstração no EF pra isso. Ele serializava os dados antes e depois de gravar e colocava essas serializações numa tabela, referenciando o registro e tipo de objeto.
Não é muito difícil de fazer, mas é de um nível técnico um pouco avançado.

Como você está gravando seus dados?
NOWLIGHTS 07/02/2024 07:17:25
#503012
Entao, ainda não existe de fato uma log de alguns registros, tenho uma tabela unica chamada user_logs, onde registro tudo ali, mas quero segregar essa tabela para melhorar a eficiencia e visibilidade para que está usando o sistema.

Basicamente tenho um metodo NewLog, onde passo o id e login do usuario logado seguido de uma string de Log, ex.: _userLogs.NewLog(_userAuth.IdUsuario, _userAuth.Login, $"Editou a agenda {agenda.IdAgenda}")

Meu sistema possui o padrao de repository, junto com a Inversão de depedência seguindo a clean archtecture.
KERPLUNK 07/02/2024 07:40:18
#503013
Não me refiro ao gravar os logs, me refiro à persistência no banco no geral. Em algum ponto isso deve ocorrer. Nesse ponto é que você pode fazer o log.

E muito bom estar usando SOLID...
NOWLIGHTS 07/02/2024 08:30:19
#503014
Alterado em 07/02/2024 08:31:50 Então, o uso do padrão repository, tem um problema que identifiquei (ou não estou sabendo usar rsrs), quando faço um update da minha entidade, basicamente o EF Core marca todas as propriedades como modificadas,

          public void Update(TEntity model)
        {
            DbSet.Attach(model);
            var entry = _context.Entry(model);
            entry.State = EntityState.Modified;
        } 



Agenda agenda = _agendaRepository.GetAsync(idAgenda);
agenda.Nome = "novo nome";
_agendaRepository.Update(agenda); // nessa parte, marco como update e isso engloba todas as propriedades como Modified justamente por marcar a entidade inteira como modified.


Talvez nesse .Update eu poderia registrar a log passando junto o usuário logado... mas o problema é que não consigo capturar exatamente as propriedades modificadas
Faz sentido um registro simples de log como um repositorio, que represente uma tablea/entidade no dominio da aplicação?
KERPLUNK 07/02/2024 11:31:27
#503015
Você não grava só as modificadas. Grava todas. Tanto antes de modificar, quanto depois. E faça com que esse processo(de logar), seja configurável. Por ser um processo que pode deixar um pouco mais lento, o usuário pode não querer. À menos que seja regra de negócio. Você pode inclusive colocar uma classe que faz essa decisão. Tipo asim:

if (BusinessRules.ShouldLog(model)){
   //gravar log
}

Daí dentro desse método "ShouldLog", você verifica por tipo de objeto ou qualquer outra coisa que decida se deve ou não gravar. Daí o retorno do método é um boolean.
Completo seria assim:

public void Update(TEntity model)
        {
            if (BusinessRules.ShouldLog(model)){
               //gravar log
            }
            DbSet.Attach(model);
            var entry = _context.Entry(model);
            entry.State = EntityState.Modified;
        }
NOWLIGHTS 07/02/2024 13:47:08
#503018
Perfeito!

No caso, essa log nao terá interação com o cliente, isso é mais para os supervisores identificar quem ta fazendo caca no sistema kakakaka (caca no sentido de modificar do jeito que não devia).

Mas então, é uma boa prática/faz sentido criar tabelas para esses 'logs'?
KERPLUNK 07/02/2024 15:27:57
#503019
Onde gravar é opcional. Pode ser no banco, pode ser em arquivo(pra não inchar o banco com um monte de informação duplicada).
É mais pra ter um histórico das coisas mesmo e conforme você implementar, pode até ter opção "desfazer" ou "voltar estado".
NOWLIGHTS 07/02/2024 16:02:07
#503022
Perfeito!
Tópico encerrado , respostas não são mais permitidas
Voltar