wake-up-neo.com

Gibt es eine bewährte Methode und eine empfohlene Alternative zu Sitzungsvariablen in MVC?

Okay, also zuerst, bevor irgendjemand versucht festzustellen, dass es sich um eine "doppelte" Frage handelt. Ich habe die meisten Posts über SO in Bezug auf ähnliche Fragen durchgesehen, aber selbst in Kombination mit allem, was gesagt wurde, bin ich immer noch in einem Dilemma in Bezug auf die endgültige oder vielleicht sollte ich einstimmig eine Einigung darüber sagen Dies.

Ich kann jedoch sagen, dass ich (basierend auf den Beiträgen) endgültig festgestellt habe, dass die Antwort auf dem Umfang der Anforderung basiert. Aber auch in Anbetracht dessen scheinen die Meinungen zu unterschiedlich zu sein, als dass ich eine Entscheidung treffen könnte, wie ich damit umgehen soll.

Meine unmittelbare Anforderung ist, dass ich variable Daten von einem Controller über viele Ansichten hinweg beibehalten muss. Genauer gesagt, ich habe einen Controller und eine entsprechende Ansicht, die die Anzahl der Artikel im Warenkorb verwaltet, und ich möchte diese Daten über mehrere Ansichten hinweg beibehalten. Ich denke, dass die _layout Ansicht die logischste Wahl für dieses ist.

Jetzt habe ich diese Aufgabe erfolgreich ausgeführt, indem ich den Wert einer Sitzungsvariablen zugewiesen habe, die aus meiner _layout-Ansicht abgerufen wird. selbst wenn der Benutzer irgendwo auf der Website navigieren sollte, bleibt die Anzahl der Artikel im Warenkorb bestehen, bis er die Website verlässt oder die Kaufabwicklung abschließt. In diesem Fall wird die Variable im Code gelöscht.

Die Beiträge, die ich gelesen habe, schienen voreingenommen zu sein, weder Sitzungsvariablen noch Cookies zu bevorzugen und Daten in einer Datenbank zu speichern. Sitzungsvariablen sind für den beabsichtigten Zweck, für den ich sie verwenden möchte, in Ordnung.

Das andere, was ich gelesen habe, besagt, dass Sitzungsvariablen die Gesamtleistung möglicherweise beeinträchtigen können, wenn auf der Site viel Verkehr herrscht, da die Informationen auf dem Server gespeichert sind.

Ich persönlich kann es nicht rechtfertigen, diese Art von Informationen in einer Datenbank zu speichern und anschließend auf die Datenbank zuzugreifen, da ich mir vorstelle, dass dies auch die Leistung der Website beeinträchtigen könnte und ein wenig übertrieben für die Speicherung temporärer Daten zu sein scheint. TempData, ViewData und ViewBag funktionieren nicht beim Speichern der Daten, daher sind sie keine logische Wahl für die IMO-Anforderung.

Wenn es eine andere gut geeignete Alternative zu der Session-Variablen gibt (die für mich funktioniert), würde ich gerne wissen, was es ist.

2 Beiträge, die im Bestreben, die besten Empfehlungen zu geben, widersprüchlich erscheinen, lassen mich etwas verwirrt.

Nachteile: Ist es ratsam, die Verwendung des Sitzungsstatus in ASP.NET MVC zu vermeiden? Wenn ja, warum und wie?

Vorteile: Es ist immer noch in Ordnung, Sitzungsvariablen in ASP.NET mvc zu verwenden, oder gibt es für einige Dinge (wie einen Einkaufswagen) eine bessere Alternative

Scheint, dass diese Frage (obwohl in vielen verschiedenen Variationen dargestellt) keine endgültige Antwort hat, die ich schließen kann.

Wenn es einen besseren Weg gibt, dies ohne Übermaß zu erreichen, dann ist das die Antwort, nach der ich suche.

Ich habe irgendwo die Verwendung von MVC-Filtern in Verbindung mit dem Startabschnitt der Global.ascx-Anwendung gelesen, aber dies scheint nicht für Variablen geeignet zu sein, die auf Controllerebene festgelegt wurden, sondern für statische Variablen.

Kann jemand vielleicht (mangels eines besseren Wortes) die vielen unterschiedlichen Meinungen zu dem Thema zerdrücken und vielleicht eine endgültigere Antwort auf die Frage geben? Ich bin sicher, dass die unterschiedlichen Meinungen ihren Platz haben und ich versuche nicht, sie zu diskreditieren. Es wäre jedoch besser, eine endgültige und möglicherweise einstimmige Antwort zu haben. dann könnte ich die anderen Beiträge sortieren, um festzustellen, was für meine Bewerbung am besten ist.

Natürlich, wenn diese Frage keine endgültige Antwort hat; Sag mir das einfach und ich werde versuchen, meine eigene Antwort aus den anderen Beiträgen abzuleiten.

Vielen Dank

================================================ =========

AKTUALISIERTE ANTWORTEN AUF ANGEBOTENE ANTWORTEN

Zwischenspeicherung und Cookies scheinen in den Antworten eine allgemeine Präferenz zu sein, ich habe jedoch auch festgestellt, dass die Zwischenspeicherung kein idealer Kandidat für die Verwendung auf mehreren Webservern ist, da die Synchronisierung ein potenzielles Problem darstellen kann.

Wenn Tim die Ehre erwiesen wird, wird angegeben, dass der Datenbankspeicher optimiert ist und Benutzer die Möglichkeit haben, zu einem späteren Zeitpunkt zurückzukehren und dort fortzufahren, wo sie aufgehört haben.

Das ist ein ausgezeichneter Punkt, aber die Wahrscheinlichkeiten vorausschauend zu betrachten; Es ist wahrscheinlich sinnvoll, da einige Benutzer möglicherweise nicht zurückgeben und nicht benötigte Daten in der Datenbank belassen.

Um die Datenbank zu optimieren und sauber zu halten (was für mich gleichermaßen relevant ist), müsste eine Wartungsaufgabe implementiert werden, die diese Datensätze basierend auf einer festgelegten Zeitschwelle automatisch ungültig macht, um diesen Umständen Rechnung zu tragen. Obwohl eine Wartungsaufgabe keine unbestreitbare Option ist, denke ich dennoch, dass dies der Aufgabe nur zu dem Zweck, als temporärer Speicher zu dienen, ein wenig mehr Arbeit hinzufügt.

Trotzdem respektiere ich Tims Empfehlung und glaube, dass es verdient ist, meiner anfänglichen Meinung bis zu einem gewissen Grad zu widersprechen. dass eine Datenbank wäre kein gangbarer Weg zu sein zum Speichern temporärer Daten scheinen; Ich denke also, der Kompromiss wäre, die Daten in einer Datenbank zu speichern (in Anbetracht des Szenarios eines Einkaufswagens oder ähnlichem), möglicherweise nach einer Kaufabwicklung. Auf diese Weise können die Daten, wie Sie zuvor angegeben haben, bei nachfolgenden Besuchen permanent nachverfolgt werden, sodass Sie eine Aufzeichnung der Transaktionen haben. Noch wichtiger ist jedoch, dass es sich um Daten dieser Transaktionen handelt, die wirklich relevant sind, um in der Datenbank zu verbleiben.

Es wurde auch festgestellt, dass Session zwar schneller ist als Database; Dies gilt jedoch nicht für Vorbehalte, die bis zu einem gewissen Grad durch andere Mechanismen wie die Nutzung des SessionStateBehavior-Attributs, das nur als ein Beispiel dient, gemindert werden können.

ABER ... Ich denke, Erik hat den Punkt mit dem Mahn-Krüger-Effekt nach Hause gebracht. Obwohl aus den hier gegebenen Inhalten und Erläuterungen für die vorgeschlagenen Antworten; Ich bezweifle ernsthaft, das Know-how einer der Personen, die geantwortet haben, ist eine Möglichkeit, fraglich. Trotzdem stimme ich in der Regel darin überein, dass die Tatsache, dass eine einstimmige Meinung eingeholt wird, meine Erwartungen etwas übertreffen kann.

Was ich genauer suchte, war ein allgemeiner Konsens für eine Technik, die eine Vielzahl von Szenarien bequem aufnehmen kann. Mit anderen Worten, etwas, das nicht nur meinem speziellen Szenario gerecht wird, sondern auch das Element der Skalierbarkeit für größere Umgebungen mit potenziell höherem Datenverkehr bietet. Auf diese Weise einer Änderung in der Programmierung würde entweder ganz oder minimal allenfalls gemildert werden.

================================================

Zusammenfassung basierend auf dem Feedback:

  1. Sitzungsvariablen scheinen kleinere Szenarien zu berücksichtigen und wenn zutreffend, aber sie können Persistenzprobleme hervorrufen, unter anderem bemerkenswerte Diskrepanzen, wie von Erik sehr ausführlich dargelegt. Diese Option passt also offensichtlich nicht zu einem skalierbaren Modell.

  2. Das Zwischenspeichern ist den Sitzungsvariablen vorzuziehen, aber auch hier nicht unbedingt die "beste" skalierbare Option, unter anderem aufgrund der potenziellen Synchronisierungskomplexität in Webserverfarmumgebungen, wie bereits erwähnt. Aber trotzdem eine Option.

  3. Der Datenbankspeicher ist skalierbar, aber für den Zweck des temporären flüchtigen Speichers ist er aus Datenbanksicht wahrscheinlich nicht die eleganteste Option, da eine regelmäßige Bereinigung erforderlich wäre. Persönlich wird dies wahrscheinlich nicht das sein, womit viele Entwickler einverstanden sein werden, da ich bereits zu Beginn meiner Karriere eine solide Grundlage für Datenbankkonzepte hatte. jedoch unter Verwendung der Datenbank für diesen Zweck kann für Web-Entwicklung von einem Programmierer Sicht genügen; Aus Sicht der DAL- und DB-Entwicklung besteht jedoch (für mich) das Potenzial, eine zusätzliche DB-Aufgabe zur Durchsetzung eines effizienten Backends zu beauftragen.

  4. Cookies scheinen eine gute Option zu sein, da sie die "wünschenswerten" Elemente von Sitzungsvariablen und Zwischenspeicherung enthalten.

================================================

FAZIT

Basierend auf den Antworten; Ich denke, COOKIES und CACHING scheinen allgemein gut abgerundete Vorschläge für bewährte Verfahren in Kombination mit Datenbankspeicherung zu sein, wenn nachträglich eine fortgesetzte Persistenz erforderlich ist. als potenziell gute Kandidaten für die Skalierbarkeit der vorgestellten.

Die endgültige Wahl zwischen 2 Daten scheint auf der Menge und dem Typ der zu speichernden Daten zu beruhen (z. B. vertraulich gegenüber nicht vertraulich und ob Bedenken bestehen, dass der Kunde die Daten an ihrem Ende ändern könnte oder nicht). Neben speziellen Überlegungen für COOKIES in der Tatsache, dass sie von den Kunden deaktiviert werden können.

Offensichtlich gibt es keine einheitliche Lösung für alle Anforderungen, wie aus den gegebenen Antworten klar hervorgeht und geschlossen wird, jedoch in Bezug auf die Skalierbarkeit. Ich kann mich irren, aber dies scheint die beste Wahl zu sein.

Weil alle Antworten gut sind; Ich werde alle Beiträge als nützlich anerkennen und Eriks Antwort als eine gut gerundete, skalierbare Gesamtlösung akzeptieren. Ich wünschte, ich könnte mehr als eine akzeptierte Antwort wählen, wie ich Tim Antwort war auch sehr gut angelegt und prägnant glauben.

Gupta Antwort war auch gut, aber ich mehr Ausarbeitung der vorgeschlagenen Antwort und nicht eine Wiederholung der vorherigen Beiträge wollte.

Danke Leute!

45
Mark

Sie werden in keiner großen Gruppe von Menschen eine einhellige Meinung zu etwas bekommen. Das ist nur die menschliche Natur. Ein Teil davon von den Stielen Dunning-Kruger-Effekt , die besagen, dass die weniger jemand weiß, über ein Thema ist, desto wahrscheinlicher sind sie auf über Wert ihrer Know-how in diesem Thema. Mit anderen Worten, viele Menschen glauben, etwas zu wissen, aber nur, weil sie nicht wissen, dass sie es nicht wissen. Ein Teil davon ist einfach, dass die Menschen unterschiedliche Erfahrungen haben und einige keine Probleme mit der Sitzung festgestellt haben, während andere in verschiedenen Situationen haben oder umgekehrt ...

Um Ihre Forschungsergebnisse zu sichern, die darauf hindeuten, dass die Antwort stark von den Anforderungen abhängt, müssen wir Ihre Anforderungen verstehen. Wenn dies eine Website mit hohem Datenverkehr und Servern mit Lastenausgleich in einer Webfarm sein soll, halten Sie sich so weit wie möglich von der Sitzung entfernt. Sicher, es ist möglich, Aktien Sitzung auf verschiedene Weise in einer Serverfarmumgebung (Session-Server, distribute Cache-Server, etc ..), aber vermeiden Sitzung wird fast immer schneller sein, wenn Sie es vermeiden können.

Wenn es sich bei Ihrer Site um einen einzelnen Server handelt und es unwahrscheinlich ist, dass er jemals darüber hinaus wächst. Und Ihre Verkehrsmuster sind relativ niedrig, dann kann eine Sitzung eine nützliche Option sein. Sie sollten sich jedoch immer darüber im Klaren sein, dass es sich bei der Sitzung um einen unzuverlässigen Speicher handelt, der jederzeit auf Ihnen verschwinden kann. Wenn der App-Pool wiederverwendet wird, ist die Sitzung beendet. Wenn eine nicht abgefangene Ausnahme zum Worker-Prozess führt, ist die Sitzung möglicherweise beendet. Wenn IIS denkt, dass nicht genügend Arbeitsspeicher vorhanden ist, ist Ihre Sitzung möglicherweise unabhängig von den konfigurierten Zeitlimitwerten nicht mehr aktiv. Sie können auch nicht immer zuverlässig benachrichtigt werden, dass eine Sitzung beendet wurde, da abgebrochene Sitzungen dies nicht tun Das Session_End-Ereignis auslösen.

Ein weiteres Problem ist, dass die Sitzung serialisiert ist. Mit anderen Worten, IIS verhindert, dass mehr als ein Thread gleichzeitig in die Sitzung schreibt, und dies geschieht häufig, indem die Sitzung gesperrt wird, während ein Thread ausgeführt wird, wenn das Schreiben nicht deaktiviert wurde session locking. Dies kann schwerwiegende Probleme verursacht in einigen Fällen, und nur ein schlechte Leistung in anderen. Sie können dies mildern durch verschiedene Verfahren mit einer nur-Lese-Session Attribut Markierung, wenn Sie es nicht in diesem Verfahren modifiziert werden werden.

Letztendlich, wenn Sie Gebrauch Sitzung wählen, dann versuchen Sie nur, um es für kleine, kurzlebige Dinge, wenn überhaupt möglich, und wenn nicht möglich, dann baut in eine Art und Weise zu „Wiedergeborenen“ die Daten, wenn die Sitzung verloren. Zum Beispiel der Anzahl der Artikel im Warenkorb Beispiel verwenden, können Sie eine Methode, die ersten Schecks zu sehen, ob der Wert ist, und wenn es nicht geht aus und lädt sie aus der Datenbank. Verwenden Sie diese Methode immer, um auf die Variable zuzugreifen, anstatt direkt von der Sitzung aus darauf zuzugreifen. Wenn die Sitzung verloren geht, wird sie nur neu geladen.

Aber gesagt hat diese ... Für die Anzahl der Elemente in einem Wagen, ich würde in der Regel ein Cookie für diese Informationen verwenden möge, da Cookies sowieso auf der Seite bei jeder Last übergeben bekommen, und das ist eine kleine diskrete Einheit von Daten . Im Allgemeinen bevorzugen Sie Sitzung für vertrauliche Daten, die Sie verhindern möchten, dass der Benutzer Änderungen vornehmen kann. Die Anzahl der Artikel im Warenkorb entspricht einfach nicht dieser Regel.

25

Wann

Datenbanken sind stark optimiert. Ein einfacher Wert wie die Anzahl der Warenkörbe ist ein guter Kandidat für die Zwischenspeicherung in der Datenbank und (hoffentlich) günstig, um ihn direkt zu berechnen. Möglicherweise handelt es sich nicht um ein Problem.

Wenn Sie jedoch andere Mechanismen ausgeschlossen haben, sind kleine benutzerspezifische Werte geeignete Kandidaten für eine Sitzung.

Cache eignet sich für standortweite Werte oder benutzerspezifische Werte mit eindeutigen Schlüsseln. Das Synchronisieren von Caches über mehrere Webserver hinweg kann jedoch schwierig sein. Der Sitzungsstatus außerhalb des Prozesses bleibt synchronisiert, da er an einem einzigen Speicherort (Datenbank oder Statusserver) gespeichert ist.

Natürlich gibt es viele Caching-Alternativen von Drittanbietern mit verschiedenen Optionen, um sie synchron zu halten.

Unabhängig davon, wo die Zählung zwischengespeichert wird, bin ich der Meinung, dass Einkaufswagen selbst in der Datenbank gespeichert werden sollten, damit Benutzer die Möglichkeit haben, später zurückzukehren und dort fortzufahren, wo sie aufgehört haben.

Performance

Wenn Sie den Sitzungsstatus "Außerhalb des Prozesses" verwenden (z. B. in einer Umgebung mit Lastenausgleich und/oder um die Dauerhaftigkeit der Sitzung zu erhöhen), wird wird auf eine Datenbank zugegriffen oder ein außerplanmäßiger Dienst aufgerufen, jedoch der Aufruf ist relativ günstig, es sei denn, Sie serialisieren große Objektdiagramme.

Die Sitzung wird einmal pro Anforderung geladen. Der nachfolgende Lesezugriff ist sehr schnell.

Das Schreiben in eine Sitzung kann die Leistung beeinträchtigen, auch wenn keine Last vorhanden ist. Warum? Die meisten modernen Anwendungen verwenden asynchrone Aufrufe. Wenn mehrere asynchrone Aufrufe einen HTTP-Handler (Seite, Controller usw.) treffen, der eine Sitzung liest/schreibt, sperrt ASP.Net die Sitzung, um den Zugriff zu serialisieren. Um dies zu vermeiden, können Sie Ihre Controller mit [SessionState( SessionStateBehavior.ReadOnly )] dekorieren.

Design

Jetzt habe ich diese Aufgabe erfolgreich ausgeführt, indem ich den Wert einer Sitzungsvariablen zugewiesen habe, die aus meiner _layout-Ansicht abgerufen wird.

Dies scheint Bedenken zu vermischen, d. H. Die Ansicht zu haben, dass der zugrunde liegende Speichermechanismus bekannt ist. Aus puristischer Sicht würde ich diesen Wert für ein Ansichtsmodell festlegen oder ihn zumindest in ViewBag einfügen. Aus praktischer Sicht schaden ein oder zwei Werte, die auf diese Weise ermittelt wurden, wahrscheinlich nichts, aber achten Sie darauf, dass sie nicht viel weiter wachsen.

Ich habe irgendwo die Verwendung von MVC-Filtern in Verbindung mit dem Startabschnitt der Global.ascx-Anwendung gelesen, aber dies scheint nicht für Variablen geeignet zu sein, die auf Controllerebene festgelegt wurden, sondern für statische Variablen.

Statische Variablen haben durchaus legitime Verwendungen, aber Sie müssen sie gründlich verstehen oder ernsthafte Probleme riskieren.

Siehe meine Antworten zu statischen Variablen in ASP.Net:

10
Tim Medora

Sitzungsalternative in verschiedenen Perspektiven: -

Wenn Sie etwas in einer Sitzung belassen, wird die primäre Regel in ASP.NET MVC verletzt. Sie können diese Optionen als Alternative zur Sitzung verwenden.

Wenn Ihre ASP.NET (MVC) -Sitzung Boxing Unboxing für das Objekt ausführt, wird der Server ein wenig belastet. Versuchen Sie, diese Idee

  1. Zwischenspeichern: - Das Speichern einer Liste oder ähnlicher großer Datenmengen in einer Sitzung eignet sich besser für das Zwischenspeichern. Sie haben die Kontrolle darüber, wann es ablaufen soll, anstatt eine Benutzersitzung durchzuführen.

  2. Wenn Ihre App von JSON/Ajax-Daten abhängt, können Sie eine der in html5 bereitgestellten Funktionen (wie WebSQL, IndexDB) verwenden. Das Cookie wird nicht verwendet, sodass Sie eine gewisse Arbeitslast auf dem Server speichern können.

3
Anirudha Gupta