JSF Allgemeine Frage zu JSF

[Spitfire777]

Hi,

ich bin grad an einem Web-Projekt dran, was ich fürs Studium machen muss.
Und zwar ist halt so die Frage zum Seiten-Workflow, den ich für JSF wählen soll.

Sagen wie mal, ich hab eine simple Verwaltung von Auto-Objekten. Also gibt's im Prinzip 4 JSF-Seiten die ich dann hätte:

• viewAuto.xhtml
• viewAlleAutos.xhtml
• editAuto.xhtml
• addAuto.xhtml

Jetzt geht's um die Anzahl der Controller-Klassen. Rein intuitiv würde ich einfach pro JSF-Seite einen Session-Scoped-Controller nehmen. Mein Prof nimmt aber z.B. einen AutoController für alles. Eigentlich wäre das doch ein Anti-Pattern von wegen God-Class, oder nicht?

Wie würdet ihr das machen?

 

[nillehammer]

Mein Prof nimmt aber z.B. einen AutoController für alles. Eigentlich wäre das doch ein Anti-Pattern von wegen God-Class, oder nicht?

Hmm, ich würd das noch weiter auftrennen. Eine Klasse, welche sich um den Zugriff auf die Datenschicht kümmert und alle Methoden für Auto (ladeEins, ladeAlle, ladeBestimmte, adde, speichere, delete) anbietet. Und in JSF würd ich tatsächlich immmer die 1:1-Beziehung zwischen JSF und Controller machen. Also eher nicht so wie Dein Prof.

 

[Sym]

Und bitte nicht in den Sessionscope, wenn es nicht sein muss.

 

[Spitfire777]

Naja, das mit dem SessionScope wäre eigentlich meine zweite Frage gewesen. Meine Anwendung wird viel mit Ajax arbeiten. Daher sollte sich ja doch eigentlich dann der Server etwas merken, oder nicht?

Außerdem ist das doch auch ein ziemlicher Performancegewinn, wenn ich z.B. ein Auto bereits einmal gesucht habe und kann diesen direkt zum Bearbeiten verwenden.

Ich komme halt von der Apache-PHP-Schiene und bei einer PHP-Anwendung ist ja alles im Prinzip "RequestScoped".

 

[Sym]

In JSF2 gibt es einen ViewScope. Wenn Du CDI verwendest, gibt es dort Frameworks, die Dir diesen Scope liefern (oder Du schreibst eine eigene Extension).

Alles was Du in den Sessionscope packst, beutelt den Speicher des Servers. Ein Applicationserver kann bei großer Last mit großen Sessions stark leiden. Meist ist die DB nicht das Bottleneck, wenn es um einfache Entitäten wie z.B. ein Auto geht.

Ich verstehe den Zusammenhang zwischen den Scopes und Ajax leider nicht so richtig. Wie genau meinst Du das?

 

[Nogothrim]

Er meint damit, dass der RequestScope für Seiten, die per AJAX Teile updaten, ungeeignet ist, da nach jedem AJAX-Request der State verloren geht, z.B. für die Sortierung einer Tabelle per AJAX-Request braucht man zwingend einen "größeren" Scope als Request. Ich würde auch die Verwendung des ViewScope empfehlen, allerdings gibt es da verschiedene Implementierungen. Die von JSF funktioniert nicht in CDI-Umgebungen, dafür braucht man Erweiterungen wie seam-faces oder myfaces-codi.
Wenn es aber eh kein Produktivsystem wird, kann man auch mit SessionScoped Beans sehr weit kommen, nur schön ist das, wie von den Vorpostern schon beschrieben, natürlich nicht.

 

[Sym]

Ah ok. Ja, der Requestscope ist dafür Banane. Aber es gibt genügend ViewScopes für CDI. Und wenn er rein JSF2 verwendet, dann bekommt er ja einen solchen geschenkt.

 

[nillehammer]

Gewisse Status kann man meiner Meinung nach auch durchaus auf Clientseite "speichern". Wenn wir an ein AJAX-Szenario denken, wo man einen Teil einer Seite ein-/ausblenden kann. Und der einzublendende Teil ist der dynamisch geladene, kann mann dies als Teil der URL (bspw. im Path oder als Parameter) auf den Client auslagern. Dann kann man mit RequestScope arbeiten. Freilich geht das für komplexere Vorgänge (Formularwizards o.ä.) dann nicht mehr.

 

[JanHH]

Ich finds eigentlich sinnvoller, die Action-Klassen in Bezug auf die Funktionalität anzulegen (also in der Tat eine "Controller"-Klasse für Auto), anstatt ein 1:1-Verbindung JSF-Seite:Java-Klasse herzustellen. Das kommt mir doch sehr JSF 1.2 mit managed "backing beans"-mässig vor. Ein modernes DI-Framework bietet da doch erheblich mehr Flexbilität, abgesehen davon bedeutet das MVC-Pattern ja nun auch gerade, das man jede Schicht für sich betrachtet logisch und sinnvoll modelliert; ein vernünftiges Zusammenspiel ergibt sich dann ja allein schon daraus (wenn man alles richtig gemacht hat). Von daher finde ich die Aufteiling "eine Action-Klasse pro Entity-Klasse" eigentlich ziemlich naheliegend.

 

[Sym]

Das verstehe ich nicht ganz. wenn Du Auto und Reifen hast, und die Reifen auf einer Seite den Autos zuordnen kannst, dann hast Du doch nicht zwei Controller. In welchen würdest Du denn die Speicher-Action schreiben?

Wenn Du Teilbereiche einer Seite wiederverwendest, die auch UI-Funktionalität enthält, dann kann man das sicher so machen. Wenn Du aber nur auf Entitäten verwaist, genügt eine Bean.

 

[Spitfire777]

Noch ein kleiner Nachtrag: Wir verwenden bei unserem Projekt Managed Beans mit CDI (Weld, Seam 3) und nicht mit JSF. Zwar bietet das Seam-3-Modul einen ViewScope, jedoch funktioniert dieser noch nicht (Bug). Siehe hier: https://issues.jboss.org/browse/SEAMFACES-44