Best Practices zum Caching in ASP.NET-Apps

Question

Ich habe eine Frage zu Caching. Ich habe eine typische n-Tier ASP.NET Web App. Ich habe einen benutzerdefinierten Cache-Wrapper (Wrapping ASP.NET Cache-Objekt) erstellt, und ich möchte die Best Practices von Caching-Daten kennen. Ich möchte kein Caching in meiner Business-Schicht verwenden (ich möchte dort keine Referenz zur System.Web-DLL hinzufügen). Gleicher Fall mit DAL. So sind die einzigen Optionen links sind:

1. Cache alles in der UI-Ebene
2. Erstellen Sie eine Cache-Ebene zwischen UI und BL (weiß nicht, wie machbar ist das?)

ich auch über das Gehörte Bevorstehendes Velocity-Caching-Framework, aber ich denke, das könnte ein Overkill sein (da meine App keine Webfarm/Cluster benötigt).

Ich kann in meinen Ansätzen schrecklich falsch liegen, so würde ich irgendwelche Vorschläge oder alternative Ansätze begrüßen, wie effektiv Daten in meinen Webprojekten zwischenzuspeichern.

Answer 1

Die Ebene zwischen Ihrer Benutzeroberfläche und BLL wäre eine Services-Ebene, die ein guter Ort für das Caching ist. Verwenden Sie einen abstrahierten Cache-Manager (example on my blog), damit Sie bei Bedarf Provider (ASP.NET-Cache, Velocity, memcached usw.) austauschen können.

Answer 2

Manchmal ist es auch eine Überlegung wert, wofür die gecachten Daten gedacht sind? Wenn es letztendlich nur statischen HTML in der UI-Ebene erzeugen wird, als diese Teile in einem Benutzersteuerelement zu umhüllen und eine @OutputCache Direktive hinzuzufügen, kann dies der effizienteste Weg sein (zumindest bei Verwendung von Webformularen). Es ist leicht, dies manchmal zu vergessen, wenn Sie sich in Caching-Frameworks festgefahren haben. Natürlich schätze ich, dass dies in vielen Fällen nicht geeignet oder Best Practice ist.