Mise en cache au niveau de la couche métier vs Mise en cache au niveau de la couche de données
J'ai toujours travaillé sur des projets où la mise en cache a été effectuée sur DAL, essentiellement au moment où vous êtes sur le point d'appeler la base de données, il vérifie si les données sont déjà là dans le cache et si c'est le cas, il ne fait tout simplement pas l'appel et renvoie plutôt ces données.
Je viens de lire récemment sur la mise en cache au niveau de la couche métier, donc essentiellement la mise en cache de tous les objets métier. Un avantage que je vois tout de suite est des temps de réponse bien meilleurs.
Quand préférez-vous l'un plutôt que l'autre? et La mise en cache dans Business Layer est-elle une pratique courante?
C'est probablement trop large pour une réponse définitive. Personnellement, je pense qu'une couche d'accès aux données est le meilleur endroit pour la mise en cache, simplement parce qu'elle est censée être très simple - les enregistrements entrent et sortent et c'est tout.
Une couche métier implémente de nombreuses règles supplémentaires de complexité plus élevée, il est donc préférable qu'elle ne aussi doive pas gérer les problèmes de disponibilité par objet en plus des problèmes de cohérence de plusieurs objets dans la même classe (ou même la même méthode) - ce serait une violation flagrante du PÉR.
(Bien sûr, je n'ai atteint cet aperçu qu'après que mes classes de service sont devenues d'une complexité ingérable quand ils ont essayé de faire à la fois la mise en cache et la configuration simultanément. Il n'y a pas de meilleur professeur que l'expérience, mais le prix est certainement élevé.)
L'accès aux données et les couches de persistance/stockage sont des endroits irrésistiblement naturels pour la mise en cache. Ils font les E/S, ce qui en fait un endroit pratique et facile pour insérer la mise en cache. J'ose dire que presque chaque couche DAL ou de persistance recevra, à mesure qu'elle mûrit, une fonction de mise en cache - si elle n'est pas conçue de cette façon dès le départ.
Le problème est l'intention . Les couches DAL et de persistance traitent des constructions de niveau relativement bas - par exemple, les enregistrements, les tables, les lignes et les blocs. Ils ne voient pas les objets "métier" ou de couche application, ou ont beaucoup d'informations sur la façon dont ils sont utilisés à des niveaux supérieurs. Lorsqu'ils voient une poignée de lignes ou une douzaine de blocs lus ou écrits, il n'est pas clair qu'ils représentent. "Le compte Jones que nous analysons actuellement" ne ressemble pas beaucoup à "certaines données de référence sur le taux d'imposition de base dont l'application n'a besoin qu'une seule fois, et auxquelles elle ne fera plus référence". À cette couche, les données sont des données sont des données.
La mise en cache à la couche DAL/persistance risque d'avoir les données de référence fiscale "à froid" là, occupant inutilement 12,2 Mo de cache et déplaçant certaines informations de compte qui, en fait, seront intensivement utilisées en seulement une minute. Même les meilleurs gestionnaires de cache font face à une connaissance limitée des structures de données et des connexions de niveau supérieur, et à peu d'informations sur les opérations à venir, donc ils reviennent à algorithmes d'estimation .
En revanche, la mise en cache de la couche application ou métier n'est pas aussi nette. Cela nécessite l'insertion d'opérations de gestion du cache ou d'indices au milieu d'une autre logique métier, ce qui rend le code métier plus complexe. Mais le compromis est le suivant: ayant plus de connaissances sur la structure des données au niveau macro et les opérations à venir, il a une bien meilleure occasion d'approximer l'efficacité optimale ("clairvoyante" ou "Bélády Min") de la mise en cache.
Il est judicieux de déterminer si l'insertion de la responsabilité de la gestion du cache dans le code métier/d'application est un jugement et dépendra des applications. Dans de nombreux cas, bien qu'il soit connu que les couches DAL/persistance ne seront pas "parfaitement correctes", le compromis est qu'elles peuvent faire un assez bon travail, qu'elles le font d'une manière architecturale "propre" et de manière beaucoup plus intensivement testable. , et que la capture de bas niveau évite d'augmenter la complexité du code d'entreprise/d'application.
Une complexité moindre encourage une plus grande exactitude et fiabilité, 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 d'entreprise de meilleure qualité et plus rapide.
La mise en cache sur le DAL est simple et directe
Votre DAL est la couche centrale d'accès aux données, ce qui signifie que tout accès aux données peut être contrôlé via les classes qui s'y trouvent. Comme la lecture et la persistance se produisent sur ces couches, il est tout aussi facile d'effacer ou de mettre à jour les entrées de cache lorsque des changements se produisent.
La mise en cache dans l'entreprise est flexible
La mise en cache sur l'entreprise permet aux développeurs de déterminer si l'utilisation concrète d'un objet bénéficiera de la mise en cache. Selon la structure des services back-end d'application ou les processus automatisés peuvent modifier les données mises en cache dans d'autres parties. Avec la mise en cache dans l'entreprise, un développeur peut déterminer si un certain objet métier aura des données périmées et des performances améliorées, ou aura l'état le plus à jour d'un objet métier au détriment des performances.