2010-11-22 11 views

Antwort

2

Der Zweck des SessionState besteht darin, Daten über die Benutzersitzung von einer HttpRequest zur nächsten persistent zu halten. In einigen Fällen ist dies eine einfachere Lösung als das manuelle Implementieren von Cookies oder das Erstellen eines Datenspeichers für Sitzungsinformationen und das Übergeben einer Kennung. MVCs Art, dies zu tun, ist die Verwendung von TempData, die SessionState umschließt. Dies bedeutet, dass es wahrscheinlich nicht erforderlich ist, direkt auf den SessionState zuzugreifen, es sei denn, Sie überschreiben einige der Core-Infrastruktur. Ich denke an ein Modell als eine metaphorischere Darstellung von Daten. Die Verwendung von Sitzungsdaten im Modell scheint nicht ganz richtig zu sein, da das Modell wahrscheinlich eine Geschäftslogik darstellt, die SessionState unnötigerweise verkomplizieren würde. System.Web.Mvc bietet eine Vielzahl von Mechanismen, die es uns ermöglichen, den Zustand zu erhalten, ohne den HttpContext direkt verwenden zu müssen. Diese Mechanismen werden als Eigenschaften des ControllerContext enthalten, die ActionFilter Filterungs Kontexten, die ExceptionContext die AuthorizationContext, die ModelBindingContext, RouteData und ViewContext. Sie helfen dabei, die vielen verschiedenen Dinge, die man in einer Sitzungsstatus-Sammlung speichern kann, in logisch getrennten Abteilungen zu trennen.

TempData ist über ControllerContext und ViewContext verfügbar. Dies ist Ihr Zugriffspunkt für die Sitzungsstatusfunktionalität. Wenn Sie die Handhabung und das Schreiben dieser Daten steuern möchten und nicht sicher sind, wo, sind Aktionsfilter ein ziemlich guter Einfügepunkt, da sie diese Bedenken aus der primären geschäftsorientierten Controller-Aktion heraushalten. Dieser Artikel untersucht die Verwendung eines ActionFilter, der den Modellstatus automatisch über Anforderungen hinweg aufrechterhält: http://blog.jorritsalverda.nl/2010/03/10/maintainable-mvc-post-redirect-get-pattern/. Ich denke, es könnte hilfreich sein. Die Frage war nicht sehr konkret ... Wenn ich Ihre Frage nicht direkt ansprach, klären Sie bitte.

1

Ich bevorzuge es, sie auf der Controller-Ebene zu halten oder sie in benutzerdefinierten Aktionsfiltern oder Modellbindern zu verstecken.

Session-Status ist wirklich ein Web-Client-Konzept, ich bevorzuge sie aus meinem Modell für die Layering Sake zu halten. Oder zumindest würde ich es in meine eigene Session- oder Kontext-Oberfläche einbinden.