Caching auf Business-Ebene vs Caching auf Datenebene

Ich habe immer an Projekten gearbeitet, in denen das Caching auf DAL durchgeführt wurde. Im Grunde genommen wird gerade beim Aufrufen der Datenbank geprüft, ob sich bereits Daten im Cache befinden gibt stattdessen diese Daten zurück.

Ich habe kürzlich über das Cachen in der Business-Schicht gelesen, also im Grunde das Cachen der gesamten Business-Objekte. Ein Vorteil, den ich sofort sehe, sind die deutlich besseren Reaktionszeiten.

Wann würden Sie eins dem anderen vorziehen? und Ist das Zwischenspeichern in Business Layer eine gängige Praxis?

Dies ist wahrscheinlich zu umfassend für eine endgültige Antwort. Persönlich bin ich der Meinung, dass eine Datenzugriffsebene der bessere Ort für das Caching ist, einfach weil sie sehr einfach sein soll - Aufzeichnungen gehen rein und raus und das war's.

Eine Business - Schicht viele zusätzliche Regeln höherer Komplexität implementiert, so dass es besser ist , wenn es nicht auch hat pro-Objekt Verfügbarkeit betrifft zusätzlich zu mehreren Objekten Konsistenz betrifft in der gleichen Klasse (oder auch die gleiche Methode) zu verwalten - das wäre eine offensichtliche Verletzung der SRP sein.

(Natürlich habe ich diese Einsicht erst erreicht, nachdem meine Serviceklassen zu einer unüberschaubaren Komplexität geworden waren, als sie versuchten, sowohl Caching als auch Konfiguration gleichzeitig durchzuführen. Es gibt keinen besseren Lehrer als Erfahrung, aber der Preis ist sicher hoch.)

Datenzugriffs- und Persistenz- / Speicherschichten sind unwiderstehlich natürliche Orte für das Caching. Sie erledigen die I / Os und machen sie so zum praktischen Ort für das Einfügen von Caching. Ich gehe davon aus, dass fast jede DAL- oder Persistenzschicht im Laufe der Zeit eine Caching-Funktion erhält - wenn sie nicht von Anfang an so konzipiert ist.

Das Problem ist die Absicht . DAL- und Persistenz-Layer befassen sich mit Konstrukten auf relativ niedriger Ebene, z. B. Datensätzen, Tabellen, Zeilen und Blöcken. Sie sehen die "Business" - oder Application-Layer-Objekte nicht oder wissen nicht genau, wie sie auf höheren Ebenen verwendet werden. Wenn sie eine Handvoll Zeilen oder ein Dutzend Blöcke lesen oder schreiben sehen, ist es nicht klar, dass sie repräsentieren. "Das derzeit analysierte Jones-Konto unterscheidet sich nicht wesentlich von" einigen grundlegenden Steuersatzreferenzdaten, die die App nur einmal benötigt und auf die sie sich nicht erneut bezieht ". In dieser Schicht sind Daten Daten sind Daten.

Beim Zwischenspeichern auf der DAL- / Persistenz-Ebene besteht die Gefahr, dass die "kalten" Steuerbezugsdaten dort gespeichert werden, unnötigerweise 12,2 MB Cache belegt werden und einige Kontoinformationen verschoben werden, die tatsächlich in nur einer Minute intensiv genutzt werden. Selbst die besten Cache-Manager haben nur wenig Wissen über die übergeordneten Datenstrukturen und -verbindungen und wissen nicht , welche Vorgänge in Kürze durchgeführt werden . Daher greifen sie auf Schätzalgorithmen zurück .

Im Gegensatz dazu ist das Caching auf Anwendungs- oder Business-Ebene bei weitem nicht so einfach. Hierfür müssen Cache-Verwaltungsvorgänge oder Hinweise in die Mitte einer anderen Geschäftslogik eingefügt werden, wodurch der Geschäftscode komplexer wird. Der Kompromiss lautet jedoch: Wenn Sie mehr über die Struktur von Daten auf Makroebene und die bevorstehenden Vorgänge wissen, haben Sie eine viel bessere Möglichkeit, die optimale Caching-Effizienz ("Hellseher" oder "Bélády Min") zu approximieren.

Ob das Einfügen der Cache-Verwaltungsverantwortung in den Geschäfts- / Anwendungscode sinnvoll ist, ist ein entscheidender Punkt und wird von Anwendung zu Anwendung unterschiedlich sein. In vielen Fällen ist es zwar bekannt, dass DAL / Persistenz-Schichten nicht "vollkommen richtig" sind, der Kompromiss besteht jedoch darin, dass sie einen ziemlich guten Job machen können, dass sie dies auf architektonisch "saubere" und viel intensiver überprüfbare Weise tun , und dass Low-Level-Catching die Komplexität von Business- / App-Code vermeidet.

Eine geringere Komplexität fördert eine höhere Korrektheit und Zuverlässigkeit sowie eine schnellere Markteinführung. Dies wird oft als großer Kompromiss angesehen - weniger perfektes Caching, aber qualitativ besserer, zeitgerechterer Geschäftscode.

Das Cachen auf dem DAL ist einfach und unkompliziert

Ihre DAL ist die zentrale Datenzugriffsschicht, dh, jeder Datenzugriff kann über die dortigen Klassen gesteuert werden. Da sowohl das Lesen als auch das Fortbestehen auf diesen Ebenen stattfinden, ist es ebenso einfach, Cache-Einträge zu löschen oder zu aktualisieren, wenn Änderungen eintreten.

Caching im Geschäft ist flexibel

Durch das Zwischenspeichern im Unternehmen können Entwickler flexibel bestimmen, ob die konkrete Verwendung eines Objekts vom Zwischenspeichern profitiert. Abhängig von der Struktur der Back-End-Dienste der Anwendung oder von automatisierten Prozessen können sich Daten ändern, die in anderen Teilen zwischengespeichert werden. Mit der Zwischenspeicherung im Geschäft kann ein Entwickler auf Kosten der Leistung feststellen, ob ein bestimmtes Geschäftsobjekt möglicherweise veraltete Daten enthält und an Leistung gewinnt oder den aktuellsten Status eines Geschäftsobjekts aufweist.