ASP.NET-Statusverwaltung in geeigneten Situationen

Question

Es gibt 6 Techniken, um Zustände in ASP.NET 3.5 zu verwalten (soweit ich weiß).

(1) View State 
(2) Cross Page Posting 
(3) Query String 
(4) Session State 
(5) Application State 
(6) Cookies 

Kann mir jemand einige geeignete Beispiele für Situationen geben, in denen ich diese Techniken anwenden sollte?

Zum Beispiel:

(*) Session State: Personalization, Buy Cart, etc. 
(*) Cookies: Saving User Credentials, etc. 

Answer 1

staatliche Verwaltungsoption

ansehen Zustand:

verwenden, wenn Sie kleine Mengen von Informationen für eine Seite speichern müssen, die an sich selbst zurück wird. Die Verwendung der ViewState-Eigenschaft bietet Funktionen mit grundlegender Sicherheit.

Steuerzustand:

verwenden, wenn Sie kleine Mengen von Zustandsinformationen für eine Kontrolle zwischen Roundtrip zum Server speichern müssen.

Versteckte Felder:

verwenden, wenn Sie kleine Mengen von Informationen für eine Seite speichern müssen, die sich zurück oder auf eine andere Seite veröffentlichen wird, und wenn die Sicherheit ist kein Thema.

Sie können ein verstecktes Feld nur auf Seiten verwenden, die an den Server gesendet werden.

Cookies:

verwenden, wenn Sie ist geringe Mengen an Informationen auf dem Client und Sicherheit speichern müssen kein Thema.

Abfragestring:

verwenden, wenn Sie kleine Mengen von Informationen von einer Seite zur anderen übertragen und Sicherheit ist kein Thema.

Sie können Abfragezeichenfolgen nur verwenden, wenn Sie dieselbe Seite oder eine andere Seite über einen Link anfordern.

Server Side Management-Optionen

Anwendungsstatus

verwenden, wenn Sie häufig geändert, globale Informationen sind zu speichern, die von vielen Benutzern verwendet wird, und die Sicherheit ist kein Thema. Speichern Sie keine großen Mengen von Informationen im Anwendungsstatus.

Sitzungsstatus

verwenden, wenn Sie kurzlebige Informationen sind zu speichern, die auf eine einzelne Sitzung und Sicherheit spezifisch ist ein Problem. Speichern Sie keine großen Mengen an Informationen im Sitzungszustand. Beachten Sie, dass ein Sitzungsstatusobjekt für die Lebensdauer jeder Sitzung in Ihrer Anwendung erstellt und verwaltet wird. In Anwendungen, die viele Benutzer hosten, kann dies erhebliche Serverressourcen belegen und die Skalierbarkeit beeinträchtigen.

Profileigenschaften

verwenden, wenn Sie benutzerspezifischen Informationen werden zu speichern, die beibehalten werden muss, nachdem der Benutzer-Sitzung ist abgelaufen und muss erneut auf Ihre Bewerbung bei zukünftigen Besuchen abgerufen werden.

Datenbank-Unterstützung

verwenden, wenn Sie große Mengen an Informationen, die Verwaltung von Transaktionen speichern, oder die Informationen müssen Anwendung und Sitzung neu gestartet werden überleben. Data Mining ist ein Problem, und Sicherheit ist ein Problem.

Answer 2

Es gibt eine Menge von Faktoren, die diese beeinflussen können, also werde ich nicht kommentieren, alle von ihnen. Aber hier sind ein paar Hinweise:

• ViewState - Dies ist nützlich, wenn Sie häufig zurück auf die gleiche Seite veröffentlichen werden (etwas, das Sie praktisch das zu tun, von ASP.Net Webforms gezwungen). Wie nützlich es ist, ändert sich je nachdem, welche Art von App du erstellst. Für öffentliche Internet-Sites sollte es sehr sparsam verwendet werden. Möglicherweise möchten Sie es sogar standardmäßig deaktivieren. Für lokale Intranet-Sites ist es ein großartiges Tool — speziell für die weniger, schwerer, Webforms-Seiten.

• Query String - Verwenden Sie dies, um den Status zu speichern, den Sie dem Benutzer erlauben müssen, eine Seite oder einen Prozess mit einem Lesezeichen zu versehen und zu einem viel späteren Zeitpunkt zurückzukehren. Selbst dann sollten Sie es auf eine Art Hash beschränken, die Sie als Schlüssel in einer Datenbanksuche verwenden können, um eine wirklich große URL zu vermeiden (obwohl Hashes ihre eigenen Probleme haben). Viele Benutzer mögen es auch, direkt mit der Abfragezeichenfolge zu experimentieren, daher kann es gefährlich sein, hier zu viel zu setzen. Es ist leicht, Daten versehentlich Benutzern zur Verfügung zu stellen, die es nicht so sehen sollen.

• Application State - Denken Sie daran, dass dies von allen Benutzern geteilt wird, verwenden Sie es entsprechend. Dinge wie View Counts können hier hingehen.

• Cookies - Verwenden Sie keine Cookies, um Benutzeranmeldeinformationen zu speichern. Sie sind einfach unverschlüsselte Textdateien. Verwenden Sie Cookies, um einen Schlüssel in der Sitzung zu speichern (auch hier können und sollten Sie jetzt Sitzungen ohne Cookies verwenden) und einfache Personalisierungseinstellungen, die für diesen Benutzer und Browser spezifisch sind. Zum Beispiel ist meine Bildschirmgröße bei der Arbeit anders als zu Hause, und das Einstellen der Anzeigegröße/Layouteinstellungen in einen Cookie ist nett, weil die Einstellungen für jeden Computer gelten, aber es wird meine Sicherheit nicht gefährden, wenn jemand anderes das liest Information.

Jetzt möchte ich dieses Konzept von der „Query String“ Abschnitt markieren:

möchten Sie vielleicht, es zu halten, um eine Art von Hash nach unten, die Sie als Schlüssel in einer Datenbank verwenden können Lookup

Wieder Hashes haben ihre eigenen Probleme, aber ich möchte darauf hinweisen, dass mehrere Artikel auf meiner Liste talk (einschließlich Abfrage-String) über Daten aus dem Client-Webbrowser auf den Webserver hochgeladen werden: Viewstate, Query String , Cookie und Seitenüberblick. Sie möchten die Daten minimieren, die Sie von Client zu Server verschieben. Dieses Konzept gilt für alle diese, und aus mehreren Gründen:

1. Ziehen Daten vom Client ist langsam für öffentliche Internet-Seiten. Selbst Breitbandverbindungen verkürzen normalerweise die für den Upload verfügbare Bandbreite.512Kpbs (in vielen Bereichen immer noch eine typische Breitband-Upload-Rate) ist nichts im Vergleich zu der Gigabit Ethernet (oder schneller) Verbindung, die wahrscheinlich zwischen Ihrer Datenbank und Ihrem Webserver sitzt. So sehr Sie sich eine Datenbankabfrage als langsam vorstellen (und das ist es auch), ist es wahrscheinlich immer noch ein viel besserer Weg zu gehen, als darauf zu warten, dass dieselben Daten vom Client ankommen.
2. Die Daten auf dem Server zu halten ist billiger, weil Sie nicht für die erforderliche Bandbreite bezahlen, um sie zum oder vom Client zu schieben, und die Bandbreite kostet oft genauso viel oder mehr als Ihre Serverhardware.
3. Es ist sicherer, denn selbst wenn der Computer eines Computers oder eine Verbindung kompromittiert ist, hat der Hacker Zugriff auf einen Hash-Schlüssel, der wahrscheinlich abläuft, wenn er es entschlüsseln kann. Natürlich kann er, wenn er falsch gemacht wird, diesen Schlüssel direkt benutzen, also müssen Sie immer noch vorsichtig sein.

Also für die meisten Dinge, was ich empfehlen kann, ist, indem sie eine Datenbank Schlüssel in der Session beginnen und dann Code müssen leicht ziehen, was Sie aus einer Datenbank benötigen auf diesen Schlüssel basiert. Wenn Sie Engpässe feststellen, geben Sie Profil ein, um herauszufinden, wo sie sich befinden, und fangen Sie an, diese Seiten oder Steuerelemente zwischenzuspeichern, oder behalten Sie diese Daten/Abfrageergebnisse direkt in der Sitzung.

Answer 3

Nicht sicher, ob Sie den Cache Objekt nach Anwendungsstatus bedeuten.

Das Cache-Objekt ist eine großartige Möglichkeit zum Verwalten des breiten Anwendungsstatus, z. den Quell- und Zählzugriff auf Ihre Website aufzuzeichnen (um zB DDoS-Attacken zu verhindern).

Answer 4

(3) Abfrage-String (4) Sitzungsstatus (5) Application State (6) Cookies

1. Viewstate

• Disclaimer: Verwenden so wenig wie möglich . Guter Punkt ist zu immer haben jeden Zustand erreichbar durch eine URL, wenn möglich.
  • F.e. Paging sollte die URL verwenden (also /url/?p=2 statt die Seite in Viewstate zu speichern)
• Verwenden, um Steuerstatus zwischen Seitenzyklen zu erhalten.
  • F.e. Speichern Sie das ausgewählte Element in einem Kontrollkästchen, damit Sie bestimmen können, ob es sich geändert hat.

2. Kreuz Seite Veröffentlichung

nicht. Siehe Haftungsausschluss für Viewstate. Verwenden Sie die URL dafür oder speichern Sie die Daten in einer Sitzung/einem Cookie/Profil, wenn viele Eigenschaften beibehalten werden müssen.

Ein großer Nachteil von CPP ist, dass der Benutzer die Schaltflächen "Zurück" und "Weiter" nicht im Webbrowser verwenden kann. Wenn ein Benutzer auf die Zurück-Schaltfläche klickt, möchte er alles auf dieser Seite rückgängig machen und die letzte erneut versuchen. Bei Verwendung von CPP, um sie durch einen Assistenten zu klicken; Dieses Verhalten ist nicht möglich ohne viele "Sind Sie sicher, dass Sie blablabblisch erneut senden möchten".

3.Abfrage String

Verwenden Sie viel. Jeder sichtbare Status, den eine Seite erreichen könnte, sollte per URL erreichbar sein. Menschen mit Screenreadern werden es Ihnen danken. Durch die Verwendung der Abfragezeichenfolge müssen keine Nur-JavaScript-Lösungen verwendet werden.

/url/?page=2 // when doing paging, don't use postback for this 
/url/?tab=advanced-search // when having tabs on top of your page 

usw.

4. Sitzungsstatus

verwenden für kurzlebige Objekte, die nur dann Sinn machen diese Zeit der Besucher Ihre Website besucht. Zum Beispiel:

• Welche Schritt eines bestimmten Assistenten wurde
• Seiten ein Benutzer erreicht hatte zuvor besuchte
• Kleine Objekte, die Sie im Cache setzen wollen, aber die sind benutzergebundene

verwenden Sie keine Sitzungen aber Profile für Dinge wie:

• Einstellungen
• Gewählte Sprache

Da diese Dinge auch beim nächsten Besuch Ihrer Website sinnvoll sind.

5. Anwendungsstatus

Nie. Verwenden Sie dafür den ASP.NET-Cache oder memcached oder ein beliebiges Caching-Framework.

6. Plätzchen

Session ID, Profil-ID für authentifizierte Benutzer; Benutzereinstellungen für anonyme Benutzer (alles in der zweiten Liste unter 4. aufgeführt).