Zustandsverwaltung

Tipp

Diese Inhalte sind ein Auszug aus dem eBook „Blazor for ASP NET Web Forms Developers for Azure“, verfügbar unter .NET Docs oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.

PDF herunterladen

Die Zustandsverwaltung ist ein wichtiges Konzept für Web Forms-Anwendungen, die durch den Ansichts-, den Sitzungs- und den Anwendungszustand sowie die Post Back-Funktionen ermöglicht wird. Diese Zustandsfeatures des Frameworks trugen dazu bei, die für eine Anwendung erforderliche Zustandsverwaltung zu verbergen und Anwendungsentwicklern den Schwerpunkt auf die Bereitstellung ihrer Funktionalität zu ermöglichen. Mit ASP.net Core und Blazor wurden einige dieser Features verschoben, und einige dieser Features wurden vollständig entfernt. In diesem Kapitel wird erläutert, wie Sie den Status verwalten und die gleichen Funktionen mit den neuen Funktionen in Blazor bereitzustellen.

Anfordern der Zustandsverwaltung mit ViewState

Bei der Erörterung der Zustandsverwaltung in der Web Forms-Anwendung denken viele Entwickler sofort an ViewState. In Web Forms verwaltet ViewState den Status des Inhalts zwischen HTTP-Anforderungen, indem ein großer codierter Textblock an den Browser zurückgesendet wird. Das ViewState-Feld kann mit dem Inhalt einer Seite, die viele Elemente enthält, überlastet werden, was möglicherweise auf mehrere Megabyte ausmacht.

Mit dem Blazor-Server unterhält die App eine fortlaufende Verbindung mit dem Server. Der Status der APP, der als Circuit bezeichnet wird, wird im Serverspeicher gehalten, während die Verbindung als aktiv betrachtet wird. Der Status wird nur verworfen, wenn der Benutzer von der App oder einer bestimmten Seite der App wegnavigiert. Alle Mitglieder der aktiven Komponenten sind zwischen Interaktionen mit dem Server verfügbar.

Dieses Feature bietet mehrere Vorteile:

• Der Komponentenstatus ist sofort verfügbar und wird zwischen Interaktionen nicht neu erstellt.
• Der Status wird nicht an den Browser übermittelt.

Allerdings gibt es einige Nachteile für den dauerhaften Komponentenzustand im Speicher, die beachtet werden sollten:

• Wenn der Server zwischen der Anforderung neu gestartet wird, geht der Status verloren.
• Die Lösung für den Lastenausgleich des App-Webservers muss dauerhafte Sitzungen enthalten, um sicherzustellen, dass alle Anforderungen desselben Browsers an denselben Server zurückgegeben werden. Wenn eine Anforderung an einen anderen Server weitergeleitet wird, geht der Status verloren.
• Die Beständigkeit des Komponentenstatus auf dem Server kann zu ungenügendem Arbeitsspeicher auf dem Webserver führen.

Verlassen Sie sich aus den vorangehenden Gründen nicht darauf, dass sich der Zustand der Komponente auf dem Server im Arbeitsspeicher befindet. Die Anwendung sollte auch einen Sicherungsdatenspeicher für Daten zwischen Anforderungen enthalten. Einige einfache Beispiele für diese Strategie:

• Bewahren Sie in einer Warenkorb-Anwendung den Inhalt der neuen Elemente auf, die dem Warenkorb in einem Datenbankdatensatz hinzugefügt werden. Wenn der Status auf dem Server verloren geht, können Sie ihn aus den Datenbankdatensätzen wiederherstellen.
• In einem mehrteiligen Webformular erwarten Ihre Benutzer, dass Ihre Anwendung die Werte zwischen den einzelnen Anforderungen speichert. Schreiben Sie die Daten zwischen den einzelnen Beiträgen Ihres Benutzers in einen Datenspeicher, sodass Sie abgerufen und in der endgültigen Antwortstrukturform zusammengefasst werden können, wenn das mehrteilige Formular abgeschlossen ist.

Weitere Informationen zum Verwalten des Zustands in Blazor-apps finden Sie unter ASP.NET Core Blazor-Zustandsverwaltung.

Status mit Sitzung beibehalten

Web Forms-Entwickler können Informationen über den aktuell aktiven Benutzer mit dem Microsoft.AspNetCore.Http.ISession Wörterbuch-Objekt verwalten. Es ist einfach genug, dem Session ein Objekt mit einem Zeichenfolgenschlüssel hinzuzufügen, und dieses Objekt wäre zu einem späteren Zeitpunkt während der Interaktion des Benutzers mit der Anwendung verfügbar. Bei dem Versuch, die Interaktion mit http zu vermeiden, vereinfachte das Session-Objekt die Zustandsverwaltung.

Die Signatur des .NET Framework Session-Objekts ist nicht mit dem ASP.NET Core Session-Objekt identisch. Sehen Sie sich die Dokumentation für die neue ASP.NET Core-Sitzung an, bevor Sie sich für die Migration und die Verwendung des neuen Features für den Sitzungszustand entscheiden.

Die Sitzung ist in ASP.NET Core und Blazor Server verfügbar, wird jedoch nicht von der Verwendung unterbunden, um Daten in einem Datenrepository entsprechend zu speichern. Der Sitzungszustand ist auch nicht funktionsfähig, wenn Besucher die Verwendung von HTTP-Cookies in Ihrer Anwendung aufgrund von Datenschutzbedenken ablehnen.

Die Konfiguration für ASP.NET Core und den Sitzungszustand ist im Artikel Sitzungs- und Zustandsverwaltung in ASP.NET Coreverfügbar.

Status der Anwendung

Das Application-Objekt im Web Forms-Framework stellt ein riesiges, über die Anforderung hinausgehendes Repository für die Interaktion mit der Konfiguration und dem Zustand des Anwendungsbereichs bereit. Der Anwendungszustand war ein idealer Ort zum Speichern verschiedener Eigenschaften der Anwendungskonfiguration, auf die von allen Anforderungen verwiesen wird, unabhängig vom Benutzer, der die Anforderung sendet. Das Problem mit dem Application-Objekt war, dass Daten nicht über mehrere Server hinweg dauerhaft gespeichert wurden. Der Status des Anwendungsobjekts ging zwischen Neustarts verloren.

Wie bei Session wird empfohlen, dass Daten in einen permanenten Sicherungsspeicher verschoben werden, auf den mehrere Serverinstanzen zugreifen können. Wenn flüchtige Daten vorhanden sind, auf die Sie über Anforderungen und Benutzer zugreifen können, können Sie sie problemlos in einem Singleton-Dienst speichern, der in Komponenten eingefügt werden kann, die diese Informationen oder Interaktionen benötigen.

Die Erstellung eines Objekts könnte der folgenden Implementierung ähneln, um den Anwendungszustand und seinen Verbrauch aufrechtzuerhalten:

public class MyApplicationState
{
    public int VisitorCounter { get; private set; } = 0;

    public void IncrementCounter() => VisitorCounter += 1;
}

app.AddSingleton<MyApplicationState>();

@inject MyApplicationState AppState

<label>Total Visitors: @AppState.VisitorCounter</label>

Das MyApplicationState-Objekt wird nur einmal auf dem Server erstellt, und der VisitorCounter-Wert wird abgerufen und in der Bezeichnung der Komponente ausgegeben. Der VisitorCounter-Wert sollte dauerhaft gespeichert und aus einem Sicherungsdatenspeicher abgerufen werden, um Dauerhaftigkeit und Skalierbarkeit zu gewährleisten.

Im Browser

Anwendungsdaten können auch auf der Clientseite auf dem Gerät des Benutzers gespeichert werden, sodass sie später verfügbar sind. Es gibt zwei Browserfunktionen, die den dauerhaften Bestand von Daten in verschiedenen Bereichen des Browsers des Benutzers ermöglichen:

• localStorage - bezieht sich auf den gesamten Browser des Benutzers. Wenn die Seite erneut geladen wird, wird der Browser geschlossen und erneut geöffnet, oder eine andere Registerkarte wird mit derselben URL und dann mit demselben localStorage vom Browser bereitgestellt
• sessionStorage - bezieht sich auf die aktuelle Registerkarte des Browsers des Benutzers. Wenn die Registerkarte noch mal geladen wird, wird der Zustand beibehalten. Wenn der Benutzer jedoch eine weitere Registerkarte für die Anwendung öffnet oder den Browser schließt und erneut öffnet, geht der Status verloren.

Sie können einen benutzerdefinierten JavaScript-Code schreiben, um mit diesen Features zu interagieren, oder es gibt eine Reihe von NuGet-Paketen, die Sie verwenden können, um diese Funktionalität bereitzustellen. Eines dieser Pakete ist Microsoft.AspNetCore.ProtectedBrowserStorage.

Anweisungen zur Verwendung dieses Pakets für die Interaktion mit localStorage und sessionStorage finden Sie im Artikel Blazor-Zustandsverwaltung.

ZurückWeiter