Ist die Websession "Bad Design"? Warum?

Neulich habe ich mit einem Kollegen darüber gesprochen, und er hat gesagt, dass die Verwendung der Benutzersitzung in einer Webanwendung einfach falsch ist. Ich antwortete, dass es je nach den von Ihnen gespeicherten Informationen falsch sein könnte, andernfalls, warum sollte ein Websitzungsdienst überhaupt von Microsoft bereitgestellt werden (wir sprachen über ASP.NET).

Er antwortete mir erneut, dass sie mir auch in MS leicht antworten könnten, dass es sich um ein schlechtes Design handele. Und dass er mir einige Whitepapers zeigen könnte, die das demonstrieren.

Leider habe ich keine Gelegenheit mehr, mich mit diesem Typen in Verbindung zu setzen, aber ich würde wirklich gerne mehr über seine Sichtweise erfahren. Hat jemand hier Informationen / Standpunkte dazu?

Ich denke nicht, dass er "schlechtes Design" so sehr meinte wie "schlechtes Üben". Im Allgemeinen sollte eine Webanwendung so zustandslos wie möglich sein. Auch wenn Sie zum Beispiel möglicherweise Benutzerinformationen benötigen, um das Anzeigen von Seiten zu autorisieren, können diese Informationen in Form eines Cookies auf dem Client-Computer gespeichert werden, und der Server überprüft die Benutzerinformationen einfach jedes Mal.

Das wäre ideal, aber Sie können sich nicht immer darauf verlassen, dass der Kunde Cookies speichern kann. Darüber hinaus muss der Benutzer in zustandsloser Weise validiert werden, was möglicherweise das Abfragen von Informationen aus der Datenbank für eine einfache Seitenanforderung umfasst. Oft ist es nur einfacher, solche Informationen in der Sitzung zu speichern.

Sobald Sie jedoch das Rubikon überschritten haben, sind viele Programmierer versucht, nicht nur Authentifizierungsinformationen in der Sitzung zu speichern, sondern auch viele andere Dinge. Dies ist ein Anti-Pattern und macht Ihre Webanwendung in der Regel stark vom Status abhängig, der eigentlich vermieden werden sollte.

Einige Programmierer würden sich auf Technologien wie Spring stützen (wenn Sie Java verwenden), um das zu entwirren, was ansonsten ein Durcheinander von Abhängigkeiten wäre, aber ich würde argumentieren, dass dies das Erstellen von Abhängigkeiten nur einfacher macht, als sie zu beseitigen. Solche Technologien sollten Ihre Entwicklung unterstützen und Ihr Anti-Pattern nicht weniger zum Problem machen.

Daher ist eine gute Faustregel, dass es wahrscheinlich eine bessere Idee ist, dies zu tun, wenn Sie es zustandslos schreiben können, oder Sie riskieren, in diese Falle zu tappen. Natürlich werden Sie in Situationen geraten, in denen dies erforderlich ist, aber im Allgemeinen sollten Sie nur Informationen speichern, die ansonsten schwer wieder abzurufen wären.

Ich denke, Sie verwechseln zwei verschiedene Themen: 1) Sitzungen und 2) das Seitenmodell von asp.net Webforms

Eine Websitzung ist für die Authentifizierung eines Benutzers erforderlich . Im Idealfall sollte eine Sitzung nur für diesen Zweck verwendet werden. Das Speichern von Benutzerdaten in einer Sitzung (sei es auf dem Server, in einem Cookie oder wie es asp.net/webforms tut: auf der Seite selbst). Niemand sollte sagen, dass eine Websitzung schlecht ist, sondern Benutzerdaten speichern in einer Sitzung ist keine schlechte Praxis. Die Gründe, warum Benutzerdaten nicht auf dem Server gespeichert werden, sind die gleichen, um globale Variablen zu vermeiden. Das Speichern von Benutzerdaten in Cookies oder auf der Seite kann zu Sicherheitsproblemen führen. Durch die Verwendung des Seitenmodells von asp.net wird auch die Staatenlosigkeit des Webs nicht berücksichtigt. Sie könnten eine Suche durchführen, um herauszufinden, warum Webformulare ein schlechtes Design sind. Sitzungen hingegen sind ein notwendiger Bestandteil von Webanwendungen.

Steuerelemente und das Speichern des Sitzungsstatus auf einer Seite sind im Grunde genommen ein Hack. Ist der Fall von MS - ein notwendiger, da sie in der Lage sein wollten, eine Entwicklungsumgebung bereitzustellen, in der Sie Seiten so gestalten können, wie Sie es in Winform-Umgebungen können.

MS haben sich der MVC-Architektur zugewandt (neueste Version - MVC 4), die eher der Rückkehr zu dem entspricht, was das Protokoll eigentlich sein sollte - zustandslos.

Es gibt Situationen, in denen der Speicherstatus immer noch praktisch ist, es sollte jedoch klar sein, dass dies eher die Ausnahme als die Regel ist.