Armazenamento em cache na camada de negócios vs Armazenamento em cache na camada de dados

Eu sempre trabalhei em projetos nos quais o cache foi feito no DAL, basicamente quando você está prestes a fazer a chamada para o banco de dados, ele verifica se os dados já estão lá no cache e, se estiver, simplesmente não faz a chamada e em vez disso, retorna esses dados.

Recentemente, eu li sobre o cache na camada de negócios, então basicamente o cache de todos os objetos de negócios. Uma vantagem que posso ver imediatamente é um tempo de resposta muito melhor.

Quando você prefere um sobre o outro? e O armazenamento em cache na camada de negócios é uma prática comum?

Provavelmente, isso é amplo demais para uma resposta definitiva. Pessoalmente, acho que uma camada de acesso a dados é o melhor lugar para armazenar em cache, simplesmente porque é suposto ser muito simples - os registros entram e saem e é isso.

Uma camada de negócios implementa muitas regras adicionais de maior complexidade; portanto, é melhor se ela também não precisar gerenciar as preocupações de disponibilidade por objeto, além das questões de consistência de vários objetos na mesma classe (ou mesmo no mesmo método) - isso ser uma violação flagrante do SRP.

(Obviamente, só cheguei a esse insight depois que minhas classes de serviço cresceram para uma complexidade incontrolável quando tentaram fazer cache e configuração simultaneamente. Não há professor melhor do que experiência, mas o preço certamente é alto.)

O acesso a dados e as camadas de persistência / armazenamento são lugares irresistivelmente naturais para armazenamento em cache. Eles estão fazendo as E / Ss, tornando-as um local prático e fácil para inserir o cache. Ouso dizer que quase todas as camadas de DAL ou persistência receberão uma função de armazenamento em cache - se ela não for projetada dessa maneira desde o início.

O problema é intencional . As camadas DAL e persistência lidam com construções de nível relativamente baixo - por exemplo, registros, tabelas, linhas e blocos. Eles não veem os objetos "comercial" ou da camada de aplicativo ou têm muito conhecimento de como estão sendo usados ​​em níveis mais altos. Quando eles veem um punhado de linhas ou uma dúzia de blocos sendo lidos ou gravados, não está claro o que eles representam. "A conta Jones que estamos analisando atualmente" não parece muito diferente de "alguns dados básicos de referência da taxa de tributação de que o aplicativo precisa apenas uma vez e aos quais não fará referência novamente". Nesta camada, dados são dados são dados.

O armazenamento em cache na camada DAL / persistência corre o risco de manter os dados de referência fiscal "frios", ocupando inútil 12,2 MB de cache e deslocando algumas informações da conta que, de fato, serão intensivamente usadas em apenas um minuto. Até os melhores gerenciadores de cache estão lidando com pouco conhecimento das estruturas e conexões de dados de nível mais alto, e com poucas informações sobre quais operações serão lançadas em breve, para que voltem aos algoritmos de estimativa de estimativa .

Por outro lado, o cache da aplicação ou da camada de negócios não é tão elegante. Requer a inserção de operações ou dicas de gerenciamento de cache no meio de outra lógica comercial, o que torna o código comercial mais complexo. Mas a desvantagem é: Tendo mais conhecimento de como os dados no nível macro são estruturados e de quais operações estão surgindo, ela tem uma oportunidade muito melhor de aproximar a eficiência ideal do cache ("clarividente" ou "Bélády Min").

Se a inserção da responsabilidade de gerenciamento de cache no código comercial / do aplicativo faz sentido é uma decisão de julgamento e variará conforme o aplicativo. Em muitos casos, embora seja sabido que as camadas DAL / persistência não serão "perfeitamente corretas", a desvantagem é que elas podem fazer um bom trabalho, mas de uma maneira arquitetonicamente "limpa" e muito mais intensivamente testável , e que a captura de baixo nível evita aumentar a complexidade do código comercial / de aplicativo.

Menor complexidade incentiva maior correção e confiabilidade e menor tempo de colocação no mercado. Isso costuma ser considerado uma grande desvantagem - armazenamento em cache menos perfeito, mas código comercial mais oportuno e de melhor qualidade.

O armazenamento em cache no DAL é direto e simples

Seu DAL é a camada central de acesso a dados, o que significa que todo e qualquer acesso a dados pode ser controlado pelas classes existentes. Como a leitura e a persistência ocorrem nessas camadas, é igualmente fácil limpar ou atualizar as entradas de cache à medida que as alterações acontecem.

O armazenamento em cache nos negócios é flexível

O armazenamento em cache nos negócios oferece aos desenvolvedores a flexibilidade de determinar se o uso concreto de um objeto se beneficiará do armazenamento em cache. Dependendo da estrutura dos serviços de back-end do aplicativo ou dos processos automatizados, poderá alterar os dados armazenados em cache em outras partes. Com o armazenamento em cache nos negócios, um desenvolvedor pode determinar se um determinado objeto de negócios terá possíveis dados obsoletos e obterá desempenho, ou terá o estado mais atualizado de um objeto de negócios à custa do desempenho.