Zustandsverwaltung

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook Blazor für ASP NET Web Forms Developers für Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Die Statusverwaltung ist ein wichtiges Konzept von Webanwendungen, das über ViewState-, Sitzungsstatus-, Anwendungsstatus- und Postbackfeatures erleichtert wird. Diese zustandsbehafteten Features des Frameworks trugen dazu bei, die für eine Anwendung erforderliche Zustandsverwaltung auszublenden und Anwendungsentwicklern zu ermöglichen, sich auf die Bereitstellung ihrer Funktionen zu konzentrieren. Mit ASP.NET Core und Blazor wurden einige dieser Features umgezogen und einige wurden komplett entfernt. In diesem Kapitel wird untersucht, wie Sie den Zustand der Anwendung beibehalten und die gleiche Funktionalität mit den neuen Funktionen in Blazor umsetzen können.

Statusverwaltung mit ViewState anfordern

Bei der Diskussion über die Zustandsverwaltung in der Webanwendung werden viele Entwickler sofort an ViewState denken. In Web Forms verwaltet ViewState den Status des Inhalts zwischen HTTP-Anforderungen, indem ein großer codierter Textblock an den Browser gesendet wird. Das Feld "ViewState" könnte mit Inhalten von einer Seite mit vielen Elementen überfordert werden, die möglicherweise auf mehrere Megabyte erweitert werden.

Mit Blazor Server unterhält die App eine fortlaufende Verbindung mit dem Server. Der Zustand der App, der als Schaltkreis bezeichnet wird, wird im Serverspeicher gehalten, während die Verbindung als aktiv betrachtet wird. Der Zustand wird nur zurückgesetzt, wenn der Benutzer von der App oder einer bestimmten App-Seite weg navigiert. Alle Mitglieder der aktiven Komponenten stehen während der Interaktionen mit dem Server zur Verfügung.

Dieses Feature bietet mehrere Vorteile:

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

Es gibt jedoch einige Nachteile bei der Persistenz des In-Memory-Komponentenzustands, die beachtet werden sollten.

• Wenn der Server zwischen der Anforderung neu gestartet wird, geht der Zustand verloren.
• Ihre Anwendungs-Webserver-Lastenausgleichslösung muss persistente Sitzungen enthalten, um sicherzustellen, dass alle Anforderungen derselben Browser-Instanz auf denselben Server zurückkehren. Wenn eine Anforderung an einen anderen Server wechselt, geht der Zustand verloren.
• Persistenz des Komponentenzustands auf dem Server kann zu Arbeitsspeicherdruck auf dem Webserver führen.

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

• Speichern Sie in einer Einkaufswagenanwendung den Inhalt neuer Elemente, die dem Warenkorb in einem Datenbankdatensatz hinzugefügt wurden. Wenn der Zustand auf dem Server verloren geht, können Sie ihn aus den Datenbankeinträgen wiederherstellen.
• In einem mehrteiligen Webformular erwarten Ihre Benutzer, dass Ihre Anwendung Werte zwischen jeder Anforderung speichert. Schreiben Sie die Daten zwischen den einzelnen Beiträgen Ihres Benutzers in einen Datenspeicher, damit sie abgerufen und in die endgültige Formularantwortstruktur zusammengefasst werden können, wenn das mehrteilige Formular abgeschlossen ist.

Weitere Informationen zum Verwalten des Staates in Blazor-Apps finden Sie unter ASP.NET Core Blazor State Management.

Status mit Sitzung beibehalten

Web Forms-Entwickler könnten Informationen über den aktuell handelnden Benutzer mit dem Microsoft.AspNetCore.Http.ISession Wörterbuchobjekt verwalten. Es ist einfach genug, ein Objekt mit einem Zeichenfolgenschlüssel zum SessionObjekt hinzuzufügen, und das Objekt wäre zu einem späteren Zeitpunkt während der Interaktionen des Benutzers mit der Anwendung verfügbar. In einem Versuch, die Verwaltung der Interaktion mit HTTP zu vermeiden, hat das Session Objekt das Verwalten des Zustands vereinfacht.

Die Signatur des .NET Framework-Objekts Session entspricht nicht dem ASP.NET Core-Objekt Session . Betrachten Sie die Dokumentation für die neue ASP.NET Core Session , bevor Sie sich für die Migration und Verwendung des neuen Sitzungszustandsfeatures 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 Sitzungsstatus ist im Artikel "Sitzung" und "Statusverwaltung" in ASP.NET Core-Artikel verfügbar.

Status der Anwendung

Das Application Objekt im Web Forms-Framework bietet ein massives Anforderungsübergreifendes Repository für die Interaktion mit Anwendungsbereichskonfiguration und -zustand. Der Anwendungsstatus war ein idealer Ort, um verschiedene Anwendungskonfigurationseigenschaften zu speichern, auf die von allen Anforderungen verwiesen würde, unabhängig davon, ob der Benutzer die Anforderung vornimmt. Das Problem mit dem Application Objekt war, dass Daten nicht auf mehreren Servern beibehalten wurden. Der Zustand des Anwendungsobjekts wurde zwischen Neustarts verloren.

Wie bei diesem Vorgang Sessionwird empfohlen, dass Daten in einen permanenten Sicherungsspeicher verschoben werden, auf den von mehreren Serverinstanzen zugegriffen werden kann. Wenn veränderliche Daten vorhanden sind, auf die Sie über Anforderungen und Benutzer zugreifen können, können Sie sie ganz einfach in einem Singletondienst speichern, der in Komponenten eingefügt werden kann, die diese Informationen oder Interaktion erfordern.

Der Aufbau eines Objekts zur Verwaltung des Anwendungszustands und dessen Verbrauch könnte der folgenden Implementierung ähneln:

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 Wert VisitorCounter wird in der Beschriftung der Komponente abgerufen und ausgegeben. Der VisitorCounter Wert sollte beibehalten und aus einem Sicherungsdatenspeicher für Haltbarkeit und Skalierbarkeit abgerufen werden.

Im Browser

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

• localStorage - bezieht sich auf den gesamten Browser des Benutzers. Wenn die Seite neu geladen wird, der Browser geschlossen und wieder geöffnet wird oder eine andere Registerkarte mit derselben URL geöffnet wird, stellt der Browser denselben localStorage bereit.
• sessionStorage – Bezieht sich auf die aktuelle Browserregisterkarte des Benutzers. Wenn die Registerkarte neu geladen wird, bleibt der Zustand bestehen. Wenn der Benutzer jedoch eine andere Registerkarte für Ihre Anwendung öffnet oder schließt und den Browser erneut öffnet, geht der Zustand verloren.

Sie können 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. Ein solches Paket ist Microsoft.AspNetCore.ProtectedBrowserStorage.

Anweisungen zur Verwendung dieses Pakets für die Interaktion mit localStorage und sessionStoragefinden Sie im Artikel "Blazor State Management" .

ZurückWeiter