Data criada - esse valor deve ser definido no BL ou DAL?

Question

A data criou um exemplo específico em que estou interessado - mas há outros bits de dados que se enquadram na mesma categoria: dados que você deseja capturar sobre qualquer entidade vagamente importante.

Onde é melhor fazer isso: lógica de negócios (BL) ou camada de acesso a dados (DAL)?

Até agora eu confiei no SQL Server's getdate() Para preencher a data criada para mim na inserção na mesa, mas agora estou começando a me perguntar se deveria estar fazendo isso mais no BL.

FYI - Isso tem sido principalmente em sistemas baseados na Web, onde você cria um objeto no BL (com base na entrada do usuário) e dispara no DAL - não é como se eu quisesse me referir ao objeto na memória por idades (Portanto, ter uma propriedade "Data criada" no objeto para uso no BL na criação do objeto não foi um problema).

Talvez haja uma terceira opção - isso me ocorre depois de ler a resposta do Marri75 que gravar duas vezes pode ser útil em alguns Senarios (uma vez nos dois locais). Você obteria o benefício de uma data/hora de consistência na camada de dados, mas ainda teria um valor orientado a BL para se referir - acho que eu dependeria dos seus casos de uso. Porém, essa opção não tem algum risco - as pessoas podem começar a usar a data errada para a coisa errada.

Answer 1

Eu diria: sim.

Talvez adquiram o hábito de definir as datas criadas e com acesso em seu BL. Então, em seu dal, sempre verifique os nulos nesses campos. Se eles forem nulos, considere sua opção: lançar uma exceção ou apenas preencher esses valores nessa camada. Uma espécie de Catch-All antes da inserção/atualização.

Eu tive o mesmo padrão que você descreve em sua pergunta. Fui então confrontado com o aplicativo Usar/Consumir UTC Timestamps e achei que apenas moveria esse comportamento para as classes BL e/ou DL. Sim, eu poderia ter usado GETUTCDATE(), mas parecia mais apropriado ter essa lógica no BL/DL.

Answer 2

Eu voto sempre no dal. Contar com datas e horários de camadas além do banco de dados tem sido uma fonte de bugs para mim no passado. Na maioria das configurações, você provavelmente é garantido uma data e um tempo consistente fora do seu banco de dados. Problemas de sincronização de tempo Os problemas de cliente - servidor e até servidor - o servidor resultaram em problemas desagradáveis, difíceis de duplicar e corrigir.