Was ist der nutzen von Staatenlosigkeit in JSF?

Laut dieser blog JSF wird staatenlos . Ist das nicht der springende Punkt bei der Verwendung von JSF ist, dass es macht das speichern und wiederherstellen des Status ist eine lästige Pflicht . Was ist der Sinn von JSF immer staatenlos ? Können Sie bitte ein Beispiel, wo dies nützlich sein kann .

InformationsquelleAutor Geek | 2013-02-15
  1. 24

    Zunächst möchte ich klarstellen, dass JSF nicht gerade "gehen stateless" auf seine ganz eigene. JSF fügt nur ein neues feature ermöglicht den Entwicklern das erstellen von stateless views/Formen auf Anfrage.

    Staat sparen ist besonders hilfreich in dynamisch manipuliert Formen mit z.B. bedingt ajax-gerenderten Teile. Es merkt sich den Zustand der form über ajax-basierte postbacks. In anderen Worten, es sind jene Formen, wo Sie unbedingt einen Blick scoped managed bean anstelle eines request scoped managed bean. Im Falle von statischen Formularen an einem request scoped bean, der Staat könnte leicht wiederhergestellt werden, auf einer pro-Anfrage-basis, basierend auf der view-Datei und daher nicht notwendigerweise gespeichert werden müssen.

    Zustand speichern hat im Fall von server-side-state-saving management jedoch eine Kosten in Bezug auf die server-Speicher-und der session-Erzeugung. Außerdem hat es den zusätzlichen Nachteil, dass ein ViewExpiredException würde auftreten, während eine postback-während der Sitzung ist abgelaufen. All dies kann gelöst werden, indem die Einstellung, der Staat spart-management auf client-Seite. Aber dies hat wiederum eine Kosten in Bezug auf die Netzwerk Bandbreite und niedriger Leistung, die aufgrund der Serialisierung.

    Beispielsweise im Falle von großen websites abdecken und eine "öffentliche" und "restricted" - Sektion, die Sie gerne verschieben der session-Erzeugung, bis der Benutzer tatsächlich eingeloggt ist. Allerdings, wenn Sie haben eine JSF login-Formular auf den öffentlichen Teil, dann würde die session noch erstellt werden, indem nur der Zugriff auf diese Seite. Dies ist eine unnötige Kosten, wenn die form hat im Grunde keine dynamischen Zustand auf eigene und gebunden, um eine request-scoped bean.

    Wahr, diese Kosten vernachlässigbar, wenn Sie state of the art-hardware, aber es ist nicht unerheblich, wenn man relativ viele Besucher und/oder relativ schlechter hardware. In diesem Fall Messen ist wissen. Auch ist es nicht immer möglich, sich vollständig zustandslos, Sie verlieren würden, den nutzen und die Erfahrung machen, dass dynamisch manipuliert Ansichten/Formulare. Sie könnte jedoch theoretisch behalten Sie den Zustand auf einer pro-Anfrage-basis durch Gefummel mit versteckten input-Felder und/oder eigene Anfrage-Parameter.

    Angemerkt werden sollte, dass die Staatenlosigkeit ist ein weiterer Nachteil, dass es theoretisch einfach durchzuführen ein CSRF-Angriff, wenn es eine offene XSS-Loch. Zum Glück, mit JSF2/Facelets ist es schon sehr schwer, eine XSS-Loch. Der einzige Weg, um das zu bekommen, ist die Verwendung einer <h:outputText escape="false"> wieder Benutzer-gesteuerte Daten.

    Siehe auch:

    • hi BalusC. Von dem, was ich verstehe, aus Ihrem Kommentar, dass ViewScoped bean ist immer noch wichtig für die ajax-Anfrage-Formular-manipulation, und es scheint mir, dass wir können nur Stateless Modus, in dem wir normalerweise gehen request-scoped bean. Ist das richtig, BalusC? Dein Beispiel, wo du sagtest For example, in case of large websites covering a "public" and "restricted" section ... wenn wir wickeln Sie das login-Formular um <f:view transient="true">, würde es das problem lösen u erwähnen?
    InformationsquelleAutor BalusC
  2. 6

    Der Punkt ist nur, um den Status beizubehalten, wenn es wirkliche Zustand zu halten.

    Eines der großen Themen mit JSF wurde die Skalierung.

    Haben Sie grundsätzlich zwei Möglichkeiten mit JSF:

    • Shop-Status auf server - Vorteile: schnelle Reaktionszeit; Nachteile: Sie müssen den boot lädt der Speicher zu mehr als etwa 2-300 Benutzer "nur surfen" z.B., bevor Sie login oder fügen Sie etwas in den Warenkorb legen

    • speichern Zustand auf client - Vorteile: entfernt das memory limit; Nachteile: erhöht die server-Bandbreite als die Komponente Baum hat, werden an den client gesendet, jeder Zeit

    Staatenlosen soll, um sicherzustellen, dass JSF verwendet werden kann, um zu dienen-Inhalte effizient, während der Nutzer hat keinen Staat erforderlich zu erhalten.

    Gibt es zusätzliche Verfeinerungen, wie beispielsweise die Möglichkeit, die Komponente Baum wiederverwendet werden, wo es Sinn macht, aber die Idee ist, lassen Sie die app besser skaliert.

    • Ihre wichtigste Punkt der Skalierung ist richtig, aber die Erklärung nicht. JSF ist nicht so schlecht, wie Sie scheinen zu denken, dass/impliziert. Statische JSF-Seiten ohne Formulare generieren keine Staat überhaupt. Nur wenn man eine Seite mit einem <h:form> Sie generieren Zustand. Plus, seit JSF 2.0 nicht die "ganze Komponente Baum" ist schon gespeichert, nur den dynamischen Teil, in der es gespeichert werden soll ("input" - Komponenten, etc., aber nicht z.B. Beschriftungen/Texte).
    • Vielleicht ich sollte haben deutlich gemacht, dass der Unterschied zwischen 1.2 und 2.0
    • Die Frage war, tagged JSF2, so würden wir davon ausgehen, dass die Antwort gezielt auf JSF2. Vielleicht hatten Sie JSF-1.x beachten Sie beim beantworten und noch nie wirklich gearbeitet haben, mit JSF2, das war schon mehr als vor 3 Jahren?
    • Wenn ich mit JSF 2.0 fand ich, dass es einige caching-Zustand zu... aber das könnte auch nur gewesen, Apache MyFaces in der Zeit...
    • Können sagen, ich möchte zur Verringerung der Staatenlosigkeit auf den V-Teil des MVC, und ich mache ein E-Commerce-website mit shop-Artikeln. Wäre das nicht der Teil der user eingeloggt sind, MÜSSEN einen Status haben, egal, was mit JSF? (Und wir könnten die Teil einer nicht-Benutzer nur "surfen") Staatenlose zu retten-server-Speicher? Ist dies eine korrekte Betrachtungsweise von Staatenlosigkeit in JSF? Könnten wir irgendwie zu verhindern, dass der Benutzer angemeldet ist staatenlos?
    InformationsquelleAutor Stephen Connolly
Schreibe einen Kommentar