Ich bin mir nicht sicher, wo ich das Caching in meinem Repository-Muster implementieren sollte.Repository Pattern - Caching
Sollte ich es in der Service-Logik oder im Repository implementieren?
GUI -> Businesslogic (Services) -> Data Access (Repositorys)
ich es im Repository/Datenzugriffsschicht umgehen würde. Der Grund dafür ist, dass es nicht Aufgabe der Business-Schicht ist, woher die Daten stammen, sondern die Aufgabe des Repositorys. Das Repository entscheidet dann basierend auf den Umständen der Datenzugriffslogik, woher die Daten stammen, aus dem Cache (wenn es nicht zu alt ist) oder aus der Live-Datenquelle.
Es ist eine Datenzugriffsangelegenheit, mehr als eine Business-Logik-Problem.
Es ist eine gute Idee, die Caching-Logik nicht direkt in Ihr Repository zu legen, da dies das Prinzip der einfachen Verantwortung (Single Responsibility Principle, SRP) und die Trennung von Problemen verletzt. SRP gibt im Wesentlichen an, dass Ihre Klassen nur einen Grund haben sollten, sich zu ändern. Wenn Sie Bedenken bezüglich der Richtlinien für den Datenzugriff und die Zwischenspeicherung in derselben Klasse zusammenführen, müssen Sie die Klasse berühren, wenn sich eine davon ändern muss. Sie werden wahrscheinlich auch feststellen, dass Sie gegen das DRY-Prinzip verstoßen, da es einfach ist, Caching-Logik unter vielen verschiedenen Repository-Methoden zu verteilen, und wenn sich eine davon ändern muss, müssen Sie am Ende viele Methoden ändern. Der bessere Ansatz besteht darin, das Proxy- oder Strategie-Muster zu verwenden, um die Caching-Logik in einem separaten Typ anzuwenden, zum Beispiel ein CachedRepository, das dann das eigentliche db-zentrische Repository verwendet, wenn der Cache leer ist. Ich habe zwei Artikel geschrieben, die zeigen, wie dies mit .NET/C# implementieren, die Sie auf meinem Blog finden, hier:
Wenn Sie Video bevorzugen, ich beschreibe auch das Muster in dem Proxy-Entwurfs-Muster auf Plural, hier:
Mehr über das Muster hier: http://deviq.com/repository-pattern/ – ssmith
Ich stimme Ihnen zu nähern. Legacy-Geschäftslogikklassen verwenden weiterhin ein nicht zwischengespeichertes Repository, und neue Geschäftslogikdienste können das neue verwenden. Sie haben weniger Einfluss auf die vorhandene Logik – equintas
Dies sollte die richtige Antwort sein – Allie
Danke für die Antwort! Ich denke, es ist auch besser für Implementierung lazy loading. – Beni