Datencache vs Sitzungsobjekt in ASP.Net

Question

Sollen dynamische Geschäftsobjekte für eine Site in der Benutzersitzung gespeichert werden oder ASP.Net Caching (Objekte wie Bestellungen, Profilinformationen usw.) verwenden?

Ich habe mit Websites gearbeitet, die Sitzungen zum Speichern von Geschäftsobjekten verwendet haben, aber ich habe mich gefragt ... Was sind die Vor- oder Nachteile des Caching?

Answer 1

Wenn die Objekte zwischen Benutzersitzungen gemeinsam genutzt werden können, verwenden Sie den Cache. Wenn die Objekte für jede Sitzung eindeutig sind - möglicherweise, weil sie von Berechtigungen gesteuert werden -, speichern Sie sie in der Sitzung. Die In-Process-Sitzung selbst wird im Cache gespeichert, sodass der entscheidende Faktor wirklich der Umfang der Daten sein sollte.

Answer 2

Der ASP.NET-Systemcache ist für die Anwendung global, da die Sitzung für den aktuellen Benutzer eindeutig ist. Wenn Sie den globalen Cache zum Speichern von Objekten verwenden möchten, müssen Sie eine Objektidentifikationsstrategie erstellen, um die richtigen Objekte für Ihre Benutzer zu erhalten.

Wenn Sie die Leistung verbessern möchten, sollten Sie den ASP.NET-Sitzungszustand besser durch einen verteilten Speichercache wie Microsofts Velocity ersetzen. Microsoft hat Artikel darüber veröffentlicht, wie die Sitzungsnutzung durch Zielgeschwindigkeit ersetzt werden kann. Sie könnten auch Memcache oder andere ähnliche Produkte in ähnlicher Weise verwenden.

Answer 3

Sitzungsobjekte sind für Nur-Benutzer-Daten geeignet, auf der anderen Seite sind Cache-Objekte besser geeignet für Daten, die für die Anwendung freigegeben sind.
Der Schlüssel zum Speichern in der einen oder anderen besteht darin, festzustellen, ob es sich bei dem, was Sie speichern möchten, um reine Benutzerdaten handelt oder ob es in der gesamten Anwendung geteilt werden soll.

Sitzung => Eine Webseite mit einer Schritt-für-Schritt-Schnittstelle (ein Online-Test zum Beispiel).
Cache => Die Informationen, die in einem Wetter Widget angezeigt werden (wie das, das Google auf seiner igoogle.com Seite hat).
Hoffe, das hilft.

Answer 4

Caching ist nur das - Caching. Sie können sich nie darauf verlassen, dass Einträge vorhanden sind. In diesem Zusammenhang müssen also keine Annahmen gemacht werden: Bereiten Sie sich darauf vor, direkt zur Datenbank (oder wo auch immer) zu gehen, um Daten erneut abzurufen.

Session, auf der anderen Seite, ist eher zum Speichern von Objekten geeignet, obwohl ich persönlich versuche, Session-Speicher zugunsten einer DB zu vermeiden. Ich mache in der Regel, dass durch den Laden hinter einer undurchsichtigen ISessionStoreService Schnittstelle abstrahiert weg:

interface ISessionStore 
{ 
    T GetEntry<T>(string key); 
    void SaveEntry<T>(string key, T entry); 
} 

und dann „abhängigkeits Injektion“ angemessene Umsetzung, sei es InmemorySessionStore, DbSessionStore oder was auch immer.

Answer 5

Obwohl Sie Ihr Business-Objekt in Cache speichern können, aber Cache ist für Leistungsverbesserung nicht State-Management entwickelt. Stellen Sie sich vor, Sie haben einen Prozess, um 1000 Datensätze aus der Datenbank zu bekommen (und es dauert ungefähr 3 Sekunden) und Sie werden es für ein paar Minuten brauchen. Sie können Ihre Objekte im Cache speichern und Ablaufdatum, Priorität und Abhängigkeit festlegen (wie SqlDependency oder FileDependency), sodass Sie für nächste Anforderungen zwischengespeicherte Daten verwenden können, anstatt sie aus der Datenbank abzurufen. Sie können Ihr Objekt in Sitzung speichern, aber Sie können die Abhängigkeit für Sitzung standardmäßig nicht festlegen. Cache hat auch ein einzigartiges Verhalten, dass, wenn das System Speicher benötigt, es Objekte aus dem Cache abhängig von seiner Priorität freigibt. Cache-Objekte sind für die Anwendung global und für alle Benutzer freigegeben, aber die Sitzung ist nicht freigegeben und kann für jeden Benutzer (Sitzung) verwendet werden.