Warum sollten Sie jemals asp.net's ViewState Speicherobjekt über das Session-Speicherobjekt verwenden?

Question

Abgesehen davon, dass der Sitzungsspeicher sitzungsübergreifend für mehr als eine Seite ist, warum sollten Sie überhaupt den Viewstate verwenden wollen, um Werte zu speichern?

Es scheint irgendwie lächerlich, irgendeine Art von Informationen außer ein paar kleinen Abfrage-String wie Werte, hin und her vom Client zum Server zu senden. Ich meine, was für eine Verschwendung von Bandbreite(!), nur für Speicherzwecke. Die Sitzung, während global über mehrere Seiten, scheint wie eine völlig überlegene Alternative zum Viewstate.

Insbesondere bei asp.net-Ajax-Steuerungen und -Varianten kann der Viewstate schnell aufgebläht werden, wenn man die verschiedenen Zustände und Variablen all dieser verschiedenen Steuerungen und HTML-Elemente verfolgt.

Aber warum gibt es dann überhaupt einen Viewstate-Speicher für Seitenvariablen und Objekte?

Vielleicht übersehe ich eine andere großartige Verwendung für den Viewstate-Speicher der Seite, weiß jemand etwas da draußen?

Vielen Dank fürs Lesen!

EDIT: Jeder hatte eine tolle Antwort, tut mir leid, wenn ich deine nicht ausgewählt habe.

Answer 1

Sitzungen laufen aus, Viewstate nicht - Sie können eine Stunde später zurückkehren und Ihr Viewstate ist immer noch verfügbar. Der Viewstate ist auch durchgängig verfügbar, wenn Sie auf der Website zurück- oder vorwärtsgehen, die Sitzung ändert sich.

Answer 2

Der ganze Grund für Viewstate oder Session ist, das Web von einem zustandslosen System in ein dynamisches, individuelles Erlebnis zu verwandeln. Wenn ein Benutzer eine Seite anfordert, können Sie nur dann an der Stelle weitermachen, an der der Benutzer aufgehört hat, wenn Sie sich an den Zustand entweder auf dem Server oder auf dem Client des Benutzers erinnern.

Viewstate ist ein Mechanismus, um den Zustand des Benutzers auf dem Client zu speichern. Session ist ein Mechanismus, um den Zustand des Benutzers auf dem Server zu speichern.

Viewstate ist ein transienter Speichermechanismus. Bei Steuerelementen, die Viewstate verwenden, wird ihr Zustand als versteckte Eingabe in die HTML-Seite eingefügt. Um Manipulationen zu verhindern, ist er signiert. Er ist jedoch nicht verschlüsselt, so dass Sie es wahrscheinlich vermeiden sollten, irgendetwas Sensibles dort zu speichern. Viewstate ist nützlich für Situationen, in denen Sie über mehrere Anfragen (Seitenaufrufe) hinweg posten wollen. Ein Beispiel hierfür ist, wenn ein Formular nicht validiert wird, weil der Benutzer vielleicht eine falsche E-Mail-Adresse eingegeben hat, und Sie das Formular so wiederherstellen wollen, wie es war, bevor der Benutzer es abgeschickt hat. Der Nachteil dabei ist, dass der Viewstate ein hungriges Tier ist und leicht 30-50% der Seitengröße ausmachen kann.

Die Sitzung hingegen wird auf dem Server gespeichert. Der Client erhält ein Token, das dem Server mitteilt, welcher Speicherblock ihm gehört. Dies kann sehr viel sicherer sein als Viewstate, da die Daten nicht immer wieder an den Benutzer zurückgesendet werden. Allerdings gibt es auch Nachteile. Ihr Server kann keinen Speicher mehr haben. Oder der Benutzer könnte die Daten verlieren, wenn seine Sitzung unterbrochen wird.

Im Allgemeinen gibt es keine "richtige" Antwort auf die Frage, welche man verwenden sollte. Es kommt ganz darauf an, was Sie erreichen wollen.

Die meisten Dinge, die mit Kontrollen zu tun haben, sollten Viewstate verwenden. Wenn Sie jedoch mit sensiblen Informationen zu tun haben, sollten Sie Session verwenden. Wenn Sie Daten haben, die nur für eine bestimmte Anzahl von Seiten gelten, sollten Sie Viewstate verwenden. Wenn es sich um Daten handelt, die Sie während des gesamten Besuchs eines Benutzers auf Ihrer Website benötigen, sollten Sie Session in Betracht ziehen.

Answer 3

Wenn Ihre Anwendung beispielsweise in einer Computerfarm läuft und Sie die Sitzung nicht für die Verwendung von Sql-Server konfigurieren können (oder die Verwendung von Sql-Server die Leistung zu sehr beeinträchtigt)

Answer 4

ViewState und Session haben unterschiedliche Geltungsbereiche. ViewState ist dazu gedacht, mehr oder weniger flüchtige Daten während "Postbacks" zu speichern, während Session dazu dient, kritische Sitzungsdaten zu speichern. Ich empfehle die Verwendung von ViewState für Zustandsdaten, die sich auf eine bestimmte "Seitensitzung" beziehen.

Wenn Ihnen das normale Verhalten von ViewState nicht gefällt, ist es ziemlich einfach, einen eigenen PageStatePersister zu schreiben und dieses Objekt die Persistenz durchführen zu lassen, z. B. mit Session oder etwas wie Memcached. Sie können dann den Standard-Persistenzmechanismus vollständig außer Kraft setzen.

Das Gute daran ist, dass Sie nahtlos weiterhin Standard-Web-Steuerelemente im .NET Framework verwenden können, die alle ViewState/ControlState für diese Art von Daten verwenden, ohne den ViewState aufzublähen. Ein Persistenzmechanismus im Serverspeicher könnte sehr effizient sein.

Answer 5

ViewState ist im Grunde nur eine versteckte Eingabe, die bei jeder Anfrage auf den Server hochgeladen und geparst werden muss. Dieses Feld wird in der Regel automatisch ausgefüllt, oft ohne dass der Programmierer dies bemerkt, und kann recht groß werden. Für viele Websites stellt dies ein Problem dar, da selbst Breitbandnutzer nur über eine sehr begrenzte Upstream-Bandbreite verfügen.

An Intranet-Standorten, an denen alle Benutzer über einen Hochgeschwindigkeits-LAN-Zugang zum Server verfügen, der für die Speicherung von Sitzungsdaten verfügbare Speicherplatz jedoch begrenzt ist, kann dies sinnvoller sein.