Empfehlungen zur ASP.NET-Zustandsverwaltung

Aktualisiert: November 2007

Zustandsverwaltung ist der Prozess, mit dem Sie Status- und Seiteninformationen über mehrere Anforderungen der dieselben oder verschiedener Seiten beibehalten. Wie in der HTTP-basierten Technologie üblich, sind Web Forms-Seiten statusfrei, d. h. sie geben nicht automatisch an, ob die Anforderungen in einer Sequenz vom selben Client stammen oder ob eine einzelne Browserinstanz eine Seite oder Site noch aktiv anzeigt. Des Weiteren werden bei jeder Schleife zum Server (Roundtrip) Seiten zerstört und wieder erstellt. Aus diesem Grund existieren Seiteninformationen nicht länger als der Lebenszyklus einer einzelnen Seite. Weitere Informationen zu Serverschleifen und dem Lebenszyklus von Web Forms-Seiten finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Seiten.

ASP.NET bietet mehrere Möglichkeiten, den Status zwischen Serverschleifen zu beizubehalten. Welche der Optionen Sie wählen, hängt sehr von Ihrer Anwendung ab und sollte auf folgenden Kriterien basieren:

• Wie viele Informationen müssen Sie speichern?

• Akzeptiert der Client beständige Cookies oder Cookies im Speicher?

• Möchten Sie die Informationen auf dem Client oder auf dem Server speichern?

• Handelt es sich um vertrauliche Informationen?

• Welche Leistungs- und Bandbreitenkriterien soll die Anwendung erfüllen?

• Über welche Fähigkeiten verfügen die Browser und die Geräte, die Sie verwenden möchten?

• Müssen Informationen für jeden Benutzer gespeichert werden?

• Wie lange müssen Sie die Informationen speichern?

• Haben Sie eine Webfarm (mehrere Server), einen Webgarten (mehrere Prozesse auf einem Computer) oder einen einzelnen Prozess, der die Anwendung bedient?

Clientseitige Zustandsverwaltungsoptionen

Beim Speichern von Informationen mithilfe von clientseitigen Optionen werden keine Serverressourcen benötigt. Diese Optionen weisen in der Regel minimale Sicherheit, jedoch schnelle Serverleistung auf, weil die Nachfrage nach Serverressourcen gering ist. Da Informationen zum Speichern an den Client gesendet werden müssen, gibt es allerdings eine praktische Grenze für die Informationsmenge, die auf diese Weise gespeichert werden kann.

Folgende clientseitigen Zustandsverwaltungsoptionen unterstützt ASP.NET:

• Ansichtszustand

• Steuerelementzustand

• Ausgeblendete Felder

• Cookies

• Abfragezeichenfolgen

Ansichtszustand

Web Forms-Seiten bieten die ViewState-Eigenschaft als eine integrierte Struktur für das automatische Beibehalten von Werten zwischen mehreren Anforderungen für dieselbe Seite. Der Ansichtszustand wird als verborgenes Feld in der Seite beibehalten. Weitere Informationen hierzu finden Sie unter Übersicht über die ASP.NET-Zustandsverwaltung.

Mit dem Ansichtszustand können Sie eigene, seitenspezifische Werte über mehrere Schleifen hinweg speichern, wenn die Seite an sich selbst zurückgesendet wird. Wenn die Anwendung z. B. benutzerspezifische Informationen beibehält, d. h. Informationen, die in der Seite verwendet werden, aber nicht Teil eines Steuerelements sind, können Sie diese Informationen als Ansichtszustand speichern.

Die Verwendung des Ansichtszustands bietet folgende Vorteile:

• Serverressourcen sind nicht erforderlich   Der Ansichtszustand ist innerhalb einer Struktur des Seitencodes enthalten.

• Einfache Implementierung   Der Ansichtszustand erfordert keine benutzerdefinierte Programmierung. Dieser Zustand ist standardmäßig aktiviert, um Zustandsdaten über Steuerelemente beizubehalten.

• Erweiterte Sicherheitsfunktionen   Die Werte im Ansichtszustand werden gehasht, komprimiert und für Unicode-Implementierungen codiert. Das bietet mehr Sicherheit als ausgeblendete Felder.

Die Verwendung des Ansichtszustands weist folgende Nachteile auf:

• Überlegungen zur Leistung   Da der Ansichtszustand in der Seite selbst gespeichert ist, wird das Anzeigen und Senden der Seite beim Speichern großer Werte verlangsamt. Dies ist besonders relevant für mobile Geräte, wo die Bandbreite oft ein einschränkendes Kriterium darstellt.

• Geräteeinschränkungen   Mobile Geräte verfügen möglicherweise nicht über die Speicherkapazität, um große Mengen an Ansichtszustandsdaten zu speichern.

• Mögliche Sicherheitsrisiken   Der Ansichtszustand ist in einem oder mehreren ausgeblendeten Feldern auf der Seite gespeichert. Obwohl der Ansichtszustand Daten in einem gehashten Format speichert, können diese noch verfälscht werden. Die Informationen im ausgeblendeten Feld können angezeigt werden, wenn die Ausgabequelle der Seite direkt angezeigt wird, wodurch ein potenzielles Sicherheitsrisiko entsteht. Weitere Informationen finden Sie unter Sicherheit für ASP.NET-Webanwendungen und Grundlegende Sicherheitshinweise für Webanwendungen.

Steuerelementzustand

Das ASP.NET-Seitenframework bietet mit der ControlState-Eigenschaft die Möglichkeit, benutzerdefinierte Steuerelementdaten zwischen den Serverbesuchen zu speichern. Sie haben z. B. ein benutzerdefiniertes Steuerelement geschrieben, das verschiedene Registerkarten hat, auf denen unterschiedliche Informationen angezeigt werden. Damit das Steuerelement wie geplant funktioniert, muss es wissen, welche Registerkarte zwischen den Schleifen ausgewählt ist. Der Ansichtszustand kann zu diesem Zweck verwendet werden. Er kann jedoch von Entwicklern auf Seitenebene deaktiviert werden, sodass Ihr Steuerelement praktisch unbrauchbar würde. Im Gegensatz zum Ansichtszustand kann der Steuerelementzustand nicht deaktiviert werden und bietet damit eine zuverlässigere Methode, Steuerelementzustandsdaten zu speichern.

Die Verwendung des Steuerelementzustands bietet folgende Vorteile:

• Serverressourcen sind nicht erforderlich   Standardmäßig wird der Steuerelementzustand in ausgeblendeten Feldern auf der Seite gespeichert.

• Zuverlässigkeit   Da der Steuerelementzustand nicht wie der Ansichtszustand deaktiviert werden kann, ist der Steuerelementzustand die zuverlässigere Methode, den Zustand von Steuerelementen zu verwalten.

• Vielseitigkeit   Es können benutzerdefinierte Adapter geschrieben werden, um zu steuern, wie und wo Steuerelementzustandsdaten gespeichert werden.

Die Verwendung des Steuerelementzustands weist folgende Nachteile auf:

• Etwas Programmierung ist erforderlich   Das ASP.NET-Seitenframework stellt zwar eine Grundlage für den Steuerelementzustand bereit, seine Dauerhaftigkeit ist jedoch benutzerdefiniert. Um den Steuerelementzustand vollständig zu nutzen, müssen Sie für das Speichern und Laden des Steuerelementzustands Code schreiben.

Ausgeblendete Felder

Sie können seitenspezifische Informationen in einem ausgeblendete Feld auf der Seite speichern, um den Status der Seite beizubehalten. Weitere Informationen über ausgeblendete Felder finden Sie unter Empfehlungen zur ASP.NET-Zustandsverwaltung.

Wenn Sie ausgeblendete Felder verwenden, ist es am Besten, nur kleine Mengen sich häufig ändernder Daten auf dem Client zu speichern.

Hinweis:
Wenn Sie ausgeblendete Felder verwenden, müssen Sie die Seiten mithilfe der HTTP-POST-Methode an den Server senden, anstatt sie mithilfe der Seiten-URL (der HTTP-GET-Methode) anzufordern.

Die Verwendung ausgeblendeter Felder bietet folgende Vorteile:

• Serverressourcen sind nicht erforderlich   Das ausgeblendete Feld wird auf der Seite gespeichert und gelesen.

• Weit verbreitete Unterstützung   Fast alle Browser und Clientgeräte unterstützen Formulare mit ausgeblendeten Feldern.

• Einfache Implementierung   Ausgeblendete Felder sind Standard-HTML-Steuerelemente, die keine komplexe Programmierlogik erfordern.

Die Verwendung ausgeblendeter Felder weist folgende Nachteile auf:

• Mögliche Sicherheitsrisiken   Das ausgeblendete Feld kann manipuliert werden. Die Informationen im ausgeblendeten Feld können angezeigt werden, wenn die Ausgabequelle der Seite direkt angezeigt wird, wodurch ein potenzielles Sicherheitsrisiko entsteht. Sie können die Inhalte eines ausgeblendeten Felds manuell ver- und entschlüsseln. Dies erfordert allerdings zusätzliche Codierung und Aufwand. Spielt Sicherheit eine Rolle, sollten Sie einen serverbasierten Ansichtszustand verwenden, sodass keine vertraulichen Informationen an den Client gesendet werden können. Weitere Informationen finden Sie unter Sicherheit für ASP.NET-Webanwendungen und Grundlegende Sicherheitshinweise für Webanwendungen.

• Einfache Speicherarchitektur   Das ausgeblendete Feld unterstützt keine umfangreichen Datentypen. Ausgeblendete Felder enthalten ein Feld für einen einzelnen Zeichenfolgenwert, in das Informationen eingegeben werden können. Zum Speichern von mehreren Werten müssen Sie begrenzte Zeichenfolgen und den Code zum Analysieren dieser Zeichenfolgen implementieren. Sie können umfangreiche Datentypen zu und von ausgeblendeten Feldern manuell serialisieren bzw. deserialisieren. Dafür ist jedoch zusätzlicher Code erforderlich. Müssen Sie umfangreiche Daten auf dem Client speichern, sollten Sie stattdessen die Verwendung eines Ansichtszustands erwägen. Im Ansichtszustand ist die Serialisierung integriert, und die Daten werden in ausgeblendeten Feldern gespeichert.

• Überlegungen zur Leistungsfähigkeit   Da ausgeblendete Felder in der Seite selbst gespeichert werden, wird das Anzeigen und Senden der Seite beim Speichern großer Werte verlangsamt.

• Speichereinschränkungen   Falls in einem ausgeblendeten Feld die Datenmenge sehr groß wird, verhindern einige Proxys und Firewalls den Zugriff auf diese Seite. Da die zulässige Höchstmenge zwischen den unterschiedlichen Firewall- und Proxyimplementierungen variiert, können große ausgeblendete Felder manchmal problematisch sein. Wenn Sie viele Datenelemente speichern müssen, sollten Sie eine der folgenden Möglichkeiten erwägen:

  • Speichern Sie jedes Element in ein separates ausgeblendetes Feld.

  • Verwenden Sie den Ansichtszustand mit aktivierter Ansichtszustandssegmentierung, wodurch Daten automatisch in mehrere ausgeblendete Felder verteilt werden.

  • Anstatt Daten auf dem Client zu speichern, sollten Sie sie auf dem Server belassen. Je mehr Daten Sie an den Client versenden, desto langsamer wird die offensichtliche Reaktionszeit der Anwendung, da der Browser mehr Daten herunterladen oder senden muss.

Cookies

Cookies eignen sich zum Speichern von kleinen Mengen sich oft ändernder Informationen auf dem Client. Die Informationen werden mit der Anforderung an den Server gesendet. Weitere Informationen über die Erstellung und das Lesen von Cookies finden Sie unter Übersicht über ASP.NET-Cookies.

Die Verwendung von Cookies bietet folgende Vorteile:

• Geregelte Ablaufzeiten konfigurieren   Die Gültigkeit des Cookie kann ablaufen, wenn die Browsersitzung endet, oder es kann unendlich auf dem Clientcomputer existieren, je nachdem, wie die Ablaufzeit auf dem Client geregelt ist.

• Serverressourcen sind nicht erforderlich   Das Cookie wird auf dem Client gespeichert und vom Server nach einer Sendung gelesen.

• Einfachheit   Ein Cookie ist eine leichte, textbasierte Struktur mit einfachen Schlüssel-Wert-Paaren.

• Datenpersistenz   Obwohl die Beständigkeit eines Cookie auf einem Clientcomputer vom Ablaufprozess eines Cookies auf dem Client und von Benutzereingaben abhängig ist, sind Cookies in der Regel die dauerhafteste Form der Datenpersistenz auf einem Client.

Die Verwendung von Cookies weist folgende Nachteile auf:

• Größenbeschränkungen   Die meisten Browser beschränken die Größe eines Cookie auf 4096 Bytes, obwohl die Unterstützung für 8192 Bytes große Cookies in den neueren Browsern und Clientgeräten üblicher wird.

• Vom Benutzer konfigurierte Verweigerung   Manche Benutzer deaktivieren die Fähigkeit des Browsers oder Clientgeräts, Cookies zu empfangen, und schränken somit diese Funktionalität ein.

• Mögliche Sicherheitsrisiken   Cookies unterliegen Manipulationen. Benutzer können Cookies auf dem Computer manipulieren, was ein potenzielles Sicherheitsrisiko darstellen oder wodurch die vom Cookie abhängige Anwendung fehlschlagen kann. Obwohl auf Cookies nur über die Domäne zugegriffen werden kann, die sie an den Client versendet hat, finden Hacker immer wieder Wege, über andere Domänen auf den Computer eines Benutzers auf Cookies zuzugreifen. Sie können ein Cookie manuell ver- und entschlüsseln. Allerdings erfordert dies zusätzliche Codierung und kann sich auf die Anwendungsleistung auswirken, da für die Ver- und Entschlüsselung Zeit benötigt wird. Weitere Informationen finden Sie unter Sicherheit für ASP.NET-Webanwendungen und Grundlegende Sicherheitshinweise für Webanwendungen.

  Hinweis:

  Cookies werden oft für die Personalisierung, d. h. zum Anpassen des Inhalts für einen bekannten Benutzer, verwendet. In den meisten Fällen ist die Identifikation eher das Problem als die Authentifizierung. Ein Cookie, das zur Identifikation verwendet wird, können Sie daher in der Regel auch sichern, indem Sie den Benutzernamen, den Kontonamen oder eine eindeutige Benutzer-ID (z. B. GUID) im Cookie speichern und es für den Zugriff auf die Infrastruktur der Benutzerpersonalisierung einer Website verwenden.

Abfragezeichenfolgen

Bei einer Abfragezeichenfolge handelt es sich um Informationen, die an das Ende einer Seiten-URL angehängt werden. Weitere Informationen finden Sie unter Übersicht über die ASP.NET-Zustandsverwaltung.

Mit einer Abfragezeichenfolge können Sie mithilfe der URL Daten zurück an die Seite oder an eine andere Seite senden. Abfragezeichenfolgen bieten eine einfache, jedoch beschränkte Möglichkeit für die Verwaltung einiger Statusinformationen. Beispielsweise sind Abfragezeichenfolgen eine einfache Möglichkeit, Informationen, z. B. Produktnummern, von einer Seite an eine andere zu übergeben, wo sie verarbeitet werden.

Die Verwendung von Abfragezeichenfolgen bietet folgende Vorteile:

• Serverressourcen sind nicht erforderlich   Die Abfragezeichenfolge ist innerhalb einer HTTP-Abfrage für eine bestimmte URL enthalten.

• Weitverbreitete Unterstützung   Fast alle Browser und Clientgeräte unterstützen die Abfrage mit Zeichenfolgen zur Übergabe von Werten.

• Einfache Implementierung   ASP.NET bietet volle Unterstützung für die Abfragezeichenfolgenmethode, einschließlich der Methoden für das Lesen von Abfragezeichenfolgen mithilfe der Params-Eigenschaft des HttpRequest-Objekts.

Die Verwendung von Abfragezeichenfolgen weist folgende Nachteile auf:

• Mögliche Sicherheitsrisiken   Die Informationen in der Abfragezeichenfolge sind für den Benutzer in der Browserbenutzeroberfläche sichtbar. Benutzer können die URL als Lesezeichen speichern oder an andere Benutzer senden und so die in der Abfragezeichenfolge enthaltenen Informationen weitergeben. Falls Ihnen die Nutzung vertraulicher Daten in Abfragezeichenfolgen unsicher erscheint, sollten Sie stattdessen ausgeblendete Felder in Formularen verwenden, die POST verwenden. Weitere Informationen finden Sie unter Sicherheit für ASP.NET-Webanwendungen und Grundlegende Sicherheitshinweise für Webanwendungen.

• Beschränkte Kapazität   Einige Browser und Clientgeräte beschränken die Länge von URLs auf 2083 Zeichen.

Clientseitige Zusammenfassung der Methodenzustandsverwaltung

In der folgenden Tabelle sind die clientseitigen Optionen für die Zustandsverwaltung aufgelistet, die in ASP.NET verfügbar sind. Darüber hinaus werden Empfehlungen ausgesprochen, wann die jeweiligen Optionen anzuwenden sind.

Zustandsverwaltungsoption	Empfohlene Verwendung
Ansichtszustand	Verwenden Sie diese Option, wenn Sie kleine Mengen von Informationen für eine Seite speichern müssen, die an sich selbst zurückgesendet wird. Die ViewState-Eigenschaft bietet Funktionalität und grundlegende Sicherheit.
Steuerelementzustand	Verwenden Sie diese Option, wenn Sie zwischen Serverschleifen kleine Mengen an Zustandsinformationen für ein Steuerelement speichern müssen.
Ausgeblendete Felder	Verwenden Sie diese Option, wenn Sie kleine Mengen von Informationen für eine Seite speichern müssen, die an sich selbst oder an eine andere Seite zurückgesendet wird, und Sicherheit kein Thema ist. Hinweis: Sie können ein ausgeblendetes Feld nur auf den Seiten verwenden, die an den Server gesendet werden.
Cookies	Verwenden Sie diese Option, wenn Sie kleine Mengen von Informationen auf dem Client speichern müssen und Sicherheit kein Thema ist.
Abfragezeichenfolge	Verwenden Sie diese Option, wenn Sie kleine Mengen von Informationen von einer Seite zur anderen übertragen und Sicherheit kein Thema ist. Hinweis: Sie können Abfragezeichenfolgen nur verwenden, wenn Sie dieselbe Seite oder eine andere Seite mithilfe eines Links anfordern.

Serverseitige Zustandsverwaltungsoptionen

Serverseitige Optionen zum Speichern von Seiteninformationen weisen in der Regel eine höhere Sicherheit als clientseitige Optionen auf. Sie können jedoch mehr Webserverressourcen in Anspruch nehmen, was zu Skalierungsproblemen führen kann, wenn die Größe des Informationsspeichers zu groß ist. ASP.NET enthält mehrere Optionen zum Implementieren von serverseitiger Zustandsverwaltung. Weitere Informationen finden Sie unter Übersicht über die ASP.NET-Zustandsverwaltung.

Folgende serverseitige Zustandsverwaltungsoptionen unterstützt ASP.NET:

• Anwendungszustand

• Sitzungszustand

• Profileigenschaften

• Datenbankunterstützung

Anwendungszustand

ASP.NET stellt den Anwendungszustand über die HttpApplicationState-Klasse als Methode zum Speichern von globalen, anwendungsspezifischen Informationen bereit, die in der gesamten Anwendung sichtbar sind. Bei Anwendungszustandsvariablen handelt es sich um globale Variablen für eine ASP.NET-Anwendung. Weitere Informationen finden Sie unter Übersicht über den ASP.NET-Anwendungszustand.

Sie können die anwendungsspezifischen Werte im Anwendungszustand speichern, der anschließend vom Server verwaltet wird. Weitere Informationen finden Sie unter Übersicht über die ASP.NET-Zustandsverwaltung.

Daten, die von mehreren Sitzungen verwendet werden und sich nicht oft ändern, sind zum Einfügen in Anwendungszustandsvariablen sehr gut geeignet.

Die Verwendung des Anwendungszustands bietet folgende Vorteile:

• Einfache Implementierung   Die Verwendung des Anwendungszustands ist einfach. ASP-Entwickler sind damit vertraut, und er stimmt mit anderen .NET Framework-Klassen überein.

• Gültigkeitsbereich der Anwendung   Da der Anwendungszustand für alle Seiten einer Anwendung zur Verfügung steht, kann es beim Speichern von Informationen im Anwendungszustand vorkommen, dass nur eine einzige Kopie der Informationen (z. B. im Gegensatz zum Beibehalten von Kopien von Informationen im Sitzungszustand oder in einzelnen Seiten) beibehalten wird.

Die Verwendung des Anwendungszustands weist folgende Nachteile auf:

• Anwendungsbereich   Der Anwendungsbereich des Anwendungszustands kann auch ein Nachteil sein. Im Anwendungszustand gespeicherte Variablen sind nur für den jeweiligen Prozess global, in dem die Anwendung ausgeführt wird, und jeder Anwendungsprozess kann unterschiedliche Werte aufweisen. Aus diesem Grund können Sie sich nicht auf den Anwendungszustand verlassen, um eindeutige Werte zu speichern oder globale Indikatoren in Webgarten- oder Webfarm-Serverkonfigurationen zu aktualisieren.

• Begrenzte Datenbeständigkeit   Weil im Anwendungszustand gespeicherte globale Daten flüchtig sind, gehen sie verloren, wenn der Webserverprozess, der sie enthält, zerstört wird. Dies kann durch das Beenden nach einer Fehlfunktion, die Aktualisierung oder das Herunterfahren des Servers ausgelöst werden.

• Ressourcenanforderungen   Der Anwendungszustand erfordert Serverspeicher, was sich auf die Leistung des Servers und die Skalierbarkeit der Anwendung auswirken kann.

Sorgfältiger Entwurf und sorgfältige Implementierung des Anwendungszustand kann die Leistung der Webanwendung erhöhen. Wenn Sie z. B. ein häufig verwendetes, relativ statisches Dataset in den Anwendungszustand platzieren, kann die Leistung der Website dadurch erhöht werden, dass die allgemeine Anzahl an Datenanforderungen für die Datenbank verringert wird. Allerdings müssen bei der Leistung Kompromisse eingegangen werden. Anwendungszustandsvariablen, die große Informationsblöcke enthalten, wirken sich nachteilig auf die Webserverleistung aus, wenn die Serverauslastung zunimmt. Der von einer im Anwendungszustand gespeicherten Variable belegte Speicher wird erst freigegeben, wenn der Wert entweder entfernt oder ersetzt wird. Daher sollten Sie Anwendungszustandsvariablen nur mit kleinen, sich nicht häufig ändernden Datasets verwenden. Weitere Informationen hierzu finden Sie unter Übersicht über die Leistung.

Sitzungszustand

ASP.NET enthält einen als HttpSessionState-Klasse verfügbaren Sitzungszustand als Methode zum Speichern von sitzungsspezifischen Informationen, die nur innerhalb der Sitzung sichtbar sind. Der ASP.NET-Sitzungszustand erkennt Anforderungen vom gleichen Browser in einem festgelegten Zeitfenster als Sitzung an. Die Variablenwerte werden für die Dauer der Sitzung beibehalten. Weitere Informationen finden Sie unter Übersicht über die ASP.NET-Zustandsverwaltung und unter Übersicht über den ASP.NET-Sitzungszustand.

Sie können sitzungsspezifische Werte und Objekte im Sitzungszustand speichern, der dann vom Server verwaltet wird und dem Browser oder Clientgerät zur Verfügung steht. Die idealen Daten zum Speichern in Sitzungszustandsvariablen sind kurzlebige, sensible Daten, die für eine individuelle Sitzung spezifisch sind.

Die Verwendung des Sitzungszustands bietet folgende Vorteile:

• Einfache Implementierung   Die Verwendung der Sitzungszustandsfunktion ist einfach. ASP-Entwickler sind damit vertraut, und sie stimmt mit anderen .NET Framework-Klassen überein.

• Sitzungsspezifische Ereignisse   Sitzungsverwaltungsereignisse können von der Anwendung ausgelöst und verwendet werden.

• Datenpersistenz   In Sitzungszustandsvariablen platzierte Daten können Neustarts des Internet Information Services (IIS) und Neustarts von Workerprozessen überdauern, ohne Sitzungsdaten zu verlieren, weil die Daten in einem anderen Prozessraum gespeichert werden. Außerdem können Sitzungszustandsdaten auch über mehre Prozesse erhalten werden, z. B. in einer Webfarm oder in einem Webgarten.

• Plattformskalierbarkeit   Der Sitzungszustand kann sowohl in computer- als auch in prozessübergreifenden Konfigurationen verwendet werden und somit die Skalierbarkeit optimieren.

• Cookiefreie Unterstützung   Der Sitzungszustand funktioniert mit Browsern, die keine HTTP-Cookies unterstützen, obwohl der Sitzungszustand am häufigsten mit Cookies verwendet wird, um Benutzeridentifizierungsfunktionen in eine Webanwendung zu integrieren. Die Verwendung des Sitzungszustands ohne Cookies erfordert jedoch die Aufnahme der Sitzungs-ID in die Abfragezeichenfolge. Dieser Aspekt wird im Abschnitt über Sicherheitsaspekte von Abfragezeichenfolgen dieses Themas behandelt. Weitere Informationen über die Verwendung des Sitzungszustands ohne Cookies finden Sie unter Verwalten von ASP.NET-Websites.

• Erweiterbarkeit   Sie können einen Sitzungszustand durch Schreiben eines eigenen Sitzungszustandsanbieters anpassen und erweitern. Sitzungszustandsdaten können anschließend in einem benutzerdefiniertem Datenformat über eine Vielzahl von Speichermechanismen gespeichert werden (z. B. Datenbanken, XML-Dateien oder sogar Webdienste). Weitere Informationen hierzu finden Sie unter Implementieren eines Sitzungszustandsspeicher-Anbieters.

Die Verwendung des Sitzungszustands weist folgende Nachteile auf:

• Überlegungen zur Leistungsfähigkeit   Sitzungszustandsvariablen bleiben im Speicher, bis sie entweder entfernt oder ersetzt werden. Daher kann sich die Leistung des Servers verringern. Sitzungszustandsvariablen, die Informationsblöcke, z. B. große Datasets enthalten, können die Webserverleistung nachteilig beeinflussen, wenn die Serverauslastung zunimmt.

Profileigenschaften

ASP.NET enthält ein Feature mit dem Namen Profileigenschaften, mit dem Sie benutzerspezifische Daten speichern können. Dieses Feature ähnelt dem Sitzungszustand, mit dem Unterschied, dass Profildaten nicht verloren gehen, wenn eine Benutzersitzung abläuft. Das Profileigenschaftenfeature verwendet ein ASP.NET-Profil, das in einem persistenten Format gespeichert und einem bestimmten Benutzer zugeordnet wird. Über das ASP.NET-Profil können Sie problemlos Benutzerinformationen verwalten, ohne eine eigene Datenbank erstellen und pflegen zu müssen. Außerdem stellt das Profil die Benutzerinformationen mithilfe einer stark typisierten API zur Verfügung, auf die Sie von überall in Ihrer Anwendung zugreifen können. Sie können Objekte eines beliebigen Typs im Profil speichern. Das ASP.NET-Profilfeature stellt ein generisches Speichersystem dar, mit dem Sie praktisch alle Arten von Daten definieren und verwalten können. Trotzdem können Sie damit Daten typsicher zur Verfügung stellen. Weitere Informationen hierzu finden Sie unter Übersicht über ASP.NET-Profileigenschaften.

Die Verwendung von Profileigenschaften bietet folgende Vorteile:

• Datenpersistenz   In Profileigenschaften platzierte Daten überdauern Neustarts des Internet Information Services (IIS) und Neustarts von Workerprozessen ohne Datenverlust, da die Daten in einem externen Mechanismus gespeichert werden. Außerdem können Profileigenschaften auch über mehre Prozesse hinweg erhalten bleiben, z. B. in einer Webfarm oder in einem Webgarten.

• Plattformskalierbarkeit   Profileigenschaften können sowohl in computer- als auch in prozessübergreifenden Konfigurationen verwendet werden und somit die Skalierbarkeit optimieren.

• Erweiterbarkeit   Um Profileigenschaften zu verwenden, müssen Sie einen Profilanbieter konfigurieren. ASP.NET enthält eine SqlProfileProvider-Klasse, mit der Sie Profildaten in einer SQL-Datenbank speichern können. Sie können jedoch auch eine eigene Profilanbieterklasse erstellen, die Profildaten in einem benutzerdefinierten Format und mit einem benutzerdefinierten Speichermechanismus speichert (z. B. in einer XML-Datei und sogar in einem Webdienst). Weitere Informationen finden Sie unter ASP.NET-Profilanbieter und Implementieren eines Profilanbieters.

Die Verwendung von Profileigenschaften weist folgende Nachteile auf:

• Überlegungen zur Leistungsfähigkeit   Profileigenschaften sind in der Regel langsamer als Sitzungszustände, da die Daten nicht im Arbeitsspeicher, sondern in einem Datenspeicher gespeichert werden.

• Zusätzliche Konfigurationsanforderungen   Beim Profileigenschaftenfeature sind im Gegensatz zu Sitzungseigenschaften sehr viele Konfigurationen vorzunehmen. Um Profileigenschaften zu verwenden, müssen Sie nicht nur einen Profilanbieter konfigurieren, sondern zusätzlich alle Profileigenschaften vorkonfigurieren, die Sie speichern möchten. Weitere Informationen finden Sie unter Übersicht über ASP.NET-Profileigenschaften und unter Definieren von ASP.NET-Profileigenschaften.

• Datenpflege   Profileigenschaften erfordern ein bestimmten Wartungsaufwand. Da Profildaten im permanenten Speicher gespeichert werden, müssen Sie sicherstellen, dass die Anwendung die entsprechenden Reinigungsmechanismen aufruft, die der Profilanbieter bereitstellt, wenn die Daten veralten.

Datenbankunterstützung

In einigen Fällen soll der Status auf der Website mithilfe der Datenbankunterstützung beibehalten werden. Normalerweise wird die Datenbankunterstützung zusammen mit Cookies oder mit dem Sitzungszustand verwendet. Auf E-Commerce-Websites werden Statusinformationen z. B. häufig mithilfe einer relationalen Datenbank beibehalten, und zwar aus folgenden Gründen:

• Sicherheit

• Personalisierung

• Konsistenz

• Data Mining

Die folgenden Funktionen sind typisch für eine Cookie-unterstützte Datenbankwebsite:

• Sicherheit   Der Besucher gibt einen Kontonamen und ein Kennwort in der Anmeldungsseite einer Website ein. Die Siteinfrastruktur fragt die Datenbank mit den Anmeldewerten ab, um festzustellen, ob der Benutzer über die Rechte zum Benutzen der Site verfügt. Wenn die Datenbank die Benutzerinformationen bestätigt, verteilt die Website ein gültiges Cookie mit einer eindeutigen ID für diesen Benutzer auf diesem Clientcomputer. Die Site gewährt dem Benutzer den Zugriff.

• Personalisierung   Aufgrund der aktivierten Sicherheitsinformationen kann die Site jeden Benutzer unterscheiden, indem sie das Cookie auf dem Clientcomputer liest. Normalerweise enthalten Sites Informationen in der Datenbank, die die Einstellungen eines Benutzers (durch eine eindeutige ID identifiziert) beschreiben. Diese Beziehung wird Personalisierung genannt. Die Site kann mithilfe der im Cookie enthaltenen eindeutigen ID die Einstellungen des Benutzers feststellen und dann den Inhalt und die Informationen gemäß den Wünschen des Benutzers anzeigen und auch zukünftig auf die Benutzereinstellungen reagieren.

• Konsistenz   Wenn Sie eine Commerce-Website erstellt haben, können Sie Transaktionsdatensätze bzgl. der vorgenommenen Käufe von Waren und Dienstleistungen auf der Site behalten. Diese Informationen können zuverlässig in der Datenbank gespeichert und von der eindeutigen Benutzer-ID referenziert werden. Mit diesen Informationen können Sie feststellen, ob eine Kauftransaktion beendet wurde, und Sie können den Aktionsverlauf nachvollziehen, falls eine Kauftransaktion fehlschlägt. Mit den Informationen können Sie auch den Benutzer über den Status einer Bestellung informieren, die in der Site erteilt wurde.

• Data Mining   Informationen über Siteverwendung, Besucher oder Produkttransaktionen können zuverlässig in der Datenbank gespeichert werden. Beispiel: Die Abteilung für Geschäftsentwicklung möchte diese aus der Site gesammelten Daten verwenden, um die Produktlinie oder die Vertriebsrichtlinien für das nächste Jahr festzulegen. Die Marketingabteilung möchte die demografischen Informationen über die Benutzer der Site untersuchen. Die Technik- und Supportabteilung möchte Transaktionen ansehen und Bereiche notieren, in denen der Verkaufsprozess verbessert werden könnte. Die meisten unternehmensweiten, relationalen Datenbanken wie Microsoft SQL Server enthalten ein umfassendes Toolset für die meisten Data Mining-Projekte.

Wenn Sie die Website so entwerfen, dass die Datenbank wiederholt anhand der eindeutigen ID während jeder allgemeinen Phase im oben erwähnte Szenario abgefragt wird, wird der Status der Site beibehalten. Auf diese Weise nimmt der Benutzer wahr, das die Site ihn oder sie erkennt und entsprechend reagiert.

Die Verwendung einer Datenbank für die Beibehaltung des Zustands bietet folgende Vorteile:

• Sicherheit   Der Zugriff auf Datenbanken erfordert eine strikte Authentifizierung und Autorisierung.

• Speicherkapazität   Sie können in einer Datenbank so viele Informationen speichern, wie Sie möchten.

• Datenpersistenz   Sie können Datenbankinformationen so lange speichern, wie Sie möchten. Darüber hinaus sind die Informationen von der Verfügbarkeit des Webservers unabhängig.

• Stabilität und Datenintegrität   Datenbanken besitzen verschiedene Funktionen zum Beibehalten sinnvoller Daten, einschließlich Trigger und referenzieller Integrität, Transaktionen usw. Wenn Sie Informationen über Transaktionen in einer Datenbank (und z. B. nicht in einem Sitzungszustand) speichern, können Sie Fehler schneller beheben.

• Eingabehilfen   Die in der Datenbank gespeicherten Daten sind für eine große Anzahl an Informationsverarbeitungstools zugänglich.

• Weitverbreitete Unterstützung   Es gibt eine Vielzahl an Datenbanktools und verfügbaren benutzerdefinierten Konfigurationen.

Die Verwendung einer Datenbank für die Beibehaltung des Zustands weist folgende Nachteile auf:

• Komplexität   Eine Datenbank zur Unterstützung der Zustandsverwaltung benötigt komplexere Hardware- und Softwarekonfigurationen.

• Überlegungen zur Leistungsfähigkeit   Minderwertige Konstruktion eines relationalen Datenmodells kann Skalierungsprobleme hervorrufen. Ebenso können auch zu viele Anfragen an die Datenbank die Serverleistung negativ beeinflussen.

Serverseitige Zusammenfassung der Methodenzustandsverwaltung

In der folgenden Tabelle sind die serverseitigen Optionen für die Zustandsverwaltung aufgelistet, die in ASP.NET verfügbar sind. Darüberhinaus werden Empfehlungen ausgesprochen, wann die jeweiligen Optionen anzuwenden sind.

Siehe auch

Konzepte

Übersicht über die ASP.NET-Zustandsverwaltung

Übersicht über ASP.NET-Cookies

Übersicht über ASP.NET-Profileigenschaften

Übersicht über den ASP.NET-Sitzungszustand

Übersicht über den ASP.NET-Anwendungszustand

Weitere Ressourcen

Neues in der ASP.NET-Zustandsverwaltung