Warum sollten Sie jemals das ViewState-Speicherobjekt von asp.net für das Sitzungsspeicherobjekt verwenden?

Question

Abgesehen davon, dass Sitzungsspeicherung sitzungsübergreifend für mehr als eine Seite ist, warum sollten Sie jemals den Ansichtszustand verwenden, um Werte zu speichern?

Es scheint irgendwie lächerlich, irgendeine Art von Informationen außer ein paar kleinen Abfragezeichenfolgen wie Werte, hin und her vom Client zum Server zu senden. Ich meine, was für eine Verschwendung von Bandbreite (!), Einfach zu Speicherzwecken. Die Sitzung, obwohl global auf mehreren Seiten, scheint eine vollständig überlegene Alternative zum Viewstate zu sein.

Vor allem mit asp.net Ajax Kontrollen und Varianten, konnte der Viewstate schnell aufgebläht werden die verschiedenen Zustände und Variablen aller dieser verschiedenen Kontrollen und HTML-Elemente verfolgen.

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

Vielleicht fehlt mir eine andere große Verwendung für die Viewstate-Speicher der Seite, weiß jemand etwas da draußen?

Danke fürs Lesen!

EDIT: Jeder hatte eine gute Antwort, Entschuldigung, wenn ich nicht deins wählte.

Answer 1

Sessions laufen aus, Viewstate nicht - Sie können eine Stunde später zurückgehen und Ihr Viewstate wird weiterhin verfügbar sein. Viewstate ist auch durchgehend verfügbar, wenn Sie auf der Website "Session Changes" zurück-/vorgehen.

Answer 2

Zum Beispiel, wenn Ihre Anwendung kann in einem Computer Farm ausgeführt werden, und Sie Sitzung nicht konfigurieren kann SQL-Server zu verwenden. (Oder SQL-Server ist zu viel von einem Performance-Treffer)

Answer 3

Sie tun eine App, wo ViewState Bloat zum größten Teil kein Problem ist, dann ist es besser, seitenspezifische Daten im ViewState zu speichern, weil es Ihrem Server hilft, besser zu arbeiten. Wenn du verrückt wirst mit einer Sitzung oder irgendeinem Caching, kannst du dich mehr verletzen, als du dir selbst hilfst.

Answer 4

ViewState ist im Wesentlichen nur eine versteckte Eingabe, die auf den Server hochgeladen und mit jeder Anfrage geparst werden muss. Dieses Feld wird normalerweise automatisch gefüllt, oft mit dem Programmierer glücklicherweise nicht bewusst, und kann ziemlich groß werden. Für viele Websites, die ein Problem darstellen, weil sogar Breitband-Benutzer eine sehr begrenzte Upstream-Bandbreite haben.

In Intranet-Sites, in denen alle Benutzer über einen schnellen LAN-Zugriff auf den Server verfügen, der für die Sitzungsdatenspeicherung verfügbare RAM jedoch eingeschränkt ist, ist dies möglicherweise sinnvoller.

Answer 5

Keine Antwort auf Ihre Frage, aber eine Ihrer Annahmen ist falsch.

Sitzungs-IDs können in der URL übergeben werden. Für die Sitzung sind keine Cookies erforderlich.

http://msdn.microsoft.com/en-us/library/aa479314.aspx

<sessionState cookieless="true" /> 

Answer 6

Viewstate und Session haben unterschiedliche Bereiche. ViewState dient dazu, mehr oder weniger transiente Daten während "Postbacks" zu speichern, während Session zum Speichern wichtiger Sitzungsstatusdaten verwendet wird. Ich empfehle, ViewState für den Status zu verwenden, der sich auf eine bestimmte "Seitensitzung" bezieht.

Wenn Sie das normale Verhalten von ViewState nicht mögen, ist es ziemlich einfach, einen eigenen PageStatePersister zu schreiben und dieses Objekt persistent zu machen, zum Beispiel mit Session oder etwas wie Memcached.Sie können dann den Standard-Persistenzmechanismus vollständig überschreiben.

Dann ist die gute Sache, Sie können nahtlos fortfahren, Standard-Websteuerelemente in .NET Framework zu verwenden, die ViewState/ControlState für diese Art von Daten verwenden, ohne den ViewState aufzublähen. Ein Persistenzmechanismus des Serverspeichers könnte sehr effizient sein.

Answer 7

Der ganze Grund für Viewstate oder Session besteht darin, das Web von einem zustandslosen System in eine dynamische, maßgeschneiderte Erfahrung zu verwandeln. Wenn ein Benutzer eine Seite anfordert, besteht die einzige Möglichkeit, den Fortgang des Benutzers fortzusetzen, darin, sich den Status entweder auf dem Server oder auf dem Client des Benutzers zu merken.

Viewstate ist ein Mechanismus zum Erinnern des Benutzerstatus auf dem Client. Sitzung ist ein Mechanismus zum Erinnern des Status des Benutzers auf dem Server.

Viewstate ist ein vorübergehender Speichermechanismus. Bei Steuerelementen, die viewstate verwenden, wird ihr Status als versteckte Eingabe in die HTML-Seite gerendert. Um Manipulationen zu verhindern, ist es signiert. Es ist jedoch nicht verschlüsselt, so dass Sie wahrscheinlich vermeiden möchten, dass etwas Sensibles da drin steckt. Viewstate ist nützlich in Situationen, in denen Sie mehrere Serien von mehreren Anfragen (Seitenladevorgänge) posten möchten. Ein Beispiel dafür ist, wenn ein Formular nicht validiert wird, weil der Benutzer möglicherweise eine ungültige E-Mail-Adresse oder etwas anderes eingegeben hat und Sie das Formular so wiederherstellen möchten, wie es vor dem Senden des Benutzers war. Der Nachteil ist, dass der Viewstate ein hungriges Biest ist und leicht 30-50% zur Seitengröße hinzufügen kann.

Session wird auf dem Server gespeichert. Der Client erhält ein Token, das dem Server mitteilt, welcher Speicherblock ihnen gehört. Dies kann viel sicherer sein als der View-Status, da die Daten nicht immer wieder an den Benutzer übertragen werden. Es gibt jedoch Kompromisse. Ihr Server kann nicht genügend Arbeitsspeicher haben. Oder der Benutzer könnte die Daten verlieren, wenn ihre Sitzung unterbrochen ist.

Im Allgemeinen gibt es keine "richtige" Antwort auf welche zu verwenden. Es geht darum, was Sie erreichen wollen.

Die meisten Dinge mit Steuerelementen sollten Viewstate verwenden. Wenn Sie jedoch mit sensiblen Informationen zu tun haben, sollten Sie Session berücksichtigen. Wenn Sie Daten für bestimmte Seiten haben, verwenden Sie viewstate. Wenn es sich um Daten handelt, die Sie während des Besuchs eines Nutzers auf Ihrer Website benötigen, beachten Sie die Session.

Answer 8

Nicht wirklich eine direkte Antwort auf Ihre Frage, aber es kann Ihr Problem lösen.

Sie können Viewstate Server Seite speichern, die Nutzlast für den Client eliminiert.

Erstellen Sie eine Klasse, die die Seite erbt, und überschreiben Sie den PageStatePersister. http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

public class RussPage : Page 
    { 
     protected override PageStatePersister PageStatePersister 
     { 
      get 
      { 
       return new SessionPageStatePersister(Page); 
      } 
     } 
    }