Les couches d'accès aux données et de persistance / stockage sont des lieux irrésistiblement naturels pour la mise en cache. Ils font les E / S, ce qui les rend pratiques et faciles pour insérer un cache. J’ose dire que presque chaque couche DAL ou couche de persistance aura, à mesure de sa maturité, une fonction de mise en cache - si elle n’est pas conçue de cette manière dès le début.
Le problème est l' intention . Les couches DAL et de persistance traitent de constructions de bas niveau, telles que des enregistrements, des tables, des lignes et des blocs. Ils ne voient pas les objets "métier" ou de la couche application, ou n'ont aucune idée de la façon dont ils sont utilisés à des niveaux plus élevés. Lorsqu'ils voient une poignée de lignes ou une douzaine de blocs en cours de lecture ou d'écriture, il n'est pas clair qu'ils représentent. "Le compte Jones que nous analysons actuellement" n'est pas très différent de "certaines données de référence du taux de taxation de base dont l'application a besoin une seule fois et auxquelles elle ne se référera plus". À cette couche, les données sont données.
La mise en cache au niveau de la couche DAL / persistance risque de laisser les données de référence fiscales «froides», occuper inutilement 12,2 Mo de cache et déplacer des informations de compte qui seront, en fait, utilisées de manière intensive en une minute à peine. Même les meilleurs gestionnaires de cache ont peu de connaissances sur les structures de données et les connexions de haut niveau, et ne savent pas quelles opérations vont avoir lieu prochainement. Ils ont donc recours aux algorithmes de guesstimation .
En revanche, la mise en cache de la couche d’application ou de la couche métier n’est pas aussi ordonnée. Cela nécessite l'insertion d'opérations de gestion de cache ou d'indications au milieu d'une autre logique métier, ce qui rend le code métier plus complexe. Mais le compromis est le suivant: mieux connaître la structure des données au niveau macro et les opérations à venir, cela leur donne une bien meilleure occasion d’approcher de l’efficacité optimale de la mise en cache ("clairvoyant" ou "Bélády Min").
Le fait de savoir si l'insertion de la responsabilité de la gestion du cache dans le code métier / d'application est un choix judicieux et varie selon les applications. Dans de nombreux cas, bien qu'il soit connu que les couches DAL / persistance ne l'obtiennent pas "parfaitement bien", le compromis est qu'elles peuvent faire un très bon travail, qu'elles le font de manière "propre" sur le plan architectural et de manière beaucoup plus testable , et que la capture de bas niveau évite d’augmenter la complexité du code métier / des applications.
Une complexité moindre favorise une exactitude et une fiabilité supérieures et un délai de mise sur le marché plus rapide. Cela est souvent considéré comme un excellent compromis: une mise en cache moins parfaite, mais un code commercial de meilleure qualité et plus rapide.