ASP.NET MVC: Bewährte Praktiken für die Speicherung des Sitzungsstatus in einer assistentenähnlichen Anwendung

Question

Angenommen, ich habe eine Webanwendung, die wie eine Reihe von Assistentenseiten zur Bearbeitung eines komplexen Objekts implementiert ist. Bis der Benutzer auf die Schaltfläche "Fertigstellen" klickt, wird das Objekt nicht im Backend-System gespeichert (eine Anforderung), so dass ich in der Zwischenzeit die gesamten Informationen über das Objekt in einer Art Sitzungszustand halten muss.

Außerdem müssen einige der Assistentenseiten Kombinations- und Listenfelder mit einer potenziell großen Anzahl von Elementen anzeigen. Diese Elemente werden mithilfe eines Webdienstes aus dem Backend-System abgerufen.

Zufälligerweise erlaubt der Assistent dem Benutzer, von einer Seite des Assistenten zu einer anderen zu springen (mit Hilfe von Registerkarten am oberen Rand des Formulars), es ist also kein einfaches "weiter, weiter... fertig".

Zusätzliche Einschränkung: Die Webanwendung läuft auf einer Webfarm und der Kunde ist der Verwendung eines serverseitigen Sitzungsstatus überdrüssig. Im besten Fall soll die Größe des Sitzungsstatus minimal gehalten werden (in der Vergangenheit gab es damit Probleme).

Im Grunde gibt es hier also zwei Probleme:

1. Wie/wo sollen die vom Benutzer im Assistenten eingegebenen Daten gespeichert werden?
2. Sollen die vom Backend empfangenen Kombinations-/Listenelemente zwischengespeichert werden und wenn ja, wo?

Optionen, die ich in Betracht ziehe:

1. Speichern des Objekts in einer WebForms-ähnlichen AnsichtZustand (durch Serialisierung in die HTML-Seite). Dies würde auch die Elemente der Kombinationsfelder einschließen. Natürlich könnte es ein Problem geben, wenn die HTML-Seiten sehr groß werden und die Webanwendung dadurch langsam wird.

2. Die Speicherung in Server-seitiger Sitzungsstatus ohne Rücksicht auf die Wünsche des Kunden und ohne zu wissen, wie die Leistung beeinflusst wird, bis sie auf der tatsächlichen Webfarm getestet wird (spät im Projekt).

Ich kann mich nicht zwischen diesen beiden entscheiden. Oder gibt es eine andere Alternative?

Answer 1

Warum überhaupt ein Cache? Sie könnten nur die Registerkarten haben, wo jede Seite ein div oder Panel ist und nur die aktuelle div in Bezug auf Ihre Registerkarte anzeigen. Auf diese Weise müssen Sie nicht zu verfolgen und verarbeiten alle Eingaben, wenn der Benutzer das Formular abschickt.

Answer 2

Ist es möglich, die Daten des Assistenten in einer temporären Tabelle in der Datenbank zu speichern? Wenn der Benutzer den Assistenten abschließt, werden die Daten aus der temporären Tabelle kopiert und gelöscht. Die temporäre Tabelle enthält einen Zeitstempel, um alte, nicht abgeschlossene Daten zu entfernen.

Answer 3

Ich kann noch ein paar weitere Optionen vorschlagen

1. Der gesamte Assistent ist eine einzige Seite, auf der die Registerkarten über Javascript auf der Client-Seite ein- und ausgeblendet werden. Dies kann jedoch dazu führen, dass die Startseite langsamer geladen wird.

2. Zwischenspeicherung der Daten auf dem Server mit dem Caching Application Block (oder etwas Ähnlichem). Dadurch können alle Benutzer eine einzige Instanz dieser Daten gemeinsam nutzen, anstatt sie über alle Sitzungen hinweg zu duplizieren. Da die Daten nun leichter sind, können Sie den Kunden vielleicht davon überzeugen, die Speicherung in der Sitzung zu erlauben.

Answer 4

In der MVC-Gemeinschaft gibt es viel Widerstand gegen die Verwendung von Sessions. Das Problem ist, dass viele von uns Entwicklern Anmeldesysteme wie eine Bank-Website aufbauen. Man könnte mit versteckten Feldern argumentieren, und das funktioniert in manchen Situationen, aber wenn wir einen Benutzer aus Sicherheits- und Compliance-Gründen zeitlich begrenzen müssen, dann gibt es mehrere Möglichkeiten. Cookies sind nicht zuverlässig. Die Verwendung von Javascript-Timern ist nicht zuverlässig und entspricht nicht den 508-Vorschriften, da das Ziel darin bestehen sollte, dass die Zeitabschaltung reibungslos verläuft. Für eine Anmeldung ist daher eine Sitzung eine gute Option. Wenn Sie die Zeit in den Client-Browser, die Server-Datenbank oder das Server-Dateisystem schreiben, müssen Sie die Zeit immer noch pro Benutzer verwalten.

Setzen Sie Sessions also sparsam ein, aber fürchten Sie sie nicht. Für die Assistenten ist es technisch möglich, versteckte Felder zu serialisieren und sie weiterzugeben. Ich vermute, dass der Bedarf und der Umfang viel größer werden und eine Autorisierungs-/Authentifizierungsimplementierung mit Sessions der Kern der Anwendung sein wird.

Answer 5

Wenn Sie Ajax nicht verwenden können (für Validierung und Dropdowns und die Möglichkeit, den Assistenten in eine Registerkarte umzuwandeln) und HTML5 nicht verwenden können (für Dropdown-Caching und die Speicherung des Formularstatus im lokalen Speicher), dann denke ich, dass es keine "Best Practices" mehr gibt und Sie auf schlechte (oder schlimmere) zurückgreifen müssen.

Da MVC in Bezug auf die Verwendung von Sessions ein Gegenspieler von WebForms ist, können Sie vielleicht einen Workaround verwenden? Zum Beispiel könnten Sie neben der Speicherung all dieser Werte in einigen temporären Datenbankeinträgen, die Sie später bereinigen müssen, Folgendes einrichten AppFabric-Erweiterung für Windows Server und verwenden Sie es, um Dropdown-Listenelemente zu speichern (und der Geltungsbereich kann für alle Benutzer gelten, so dass Sie, wenn mehrere Benutzer das System gleichzeitig verwenden, nur einen Aufruf an den Webdienst zur Aktualisierung des Cache benötigen) und auch, um Ihre Objekte zwischen den Schritten vorübergehend zu speichern. Sie können Ihre temporären Objekte in AppFabric so einstellen, dass sie automatisch ablaufen, so dass eine Bereinigung nicht notwendig ist. Es kann auch dazu beitragen, andere Teile Ihres Systems zu beschleunigen, wenn Sie ein anderes System ausgiebig über Webdienste aufrufen.