Best Practices in JSF: Modell, Aktionen, Getter, Navigation, Phaselistener

7

Ich bin in ein Projekt gekommen, um die JSF-Implementierung neu zu factorisieren. Der bestehende Code entspricht nicht den JSF-Standards. Um das zu erreichen, lerne ich alle Konzepte in JSF (ich habe bereits Erfahrung mit JSF). Um genau zu sein, möchte ich Fragen stellen, was ich im Sinn habe.

  • Was ist im MVC-Muster eine Modellkomponente im JSF? Ist es die Managed Bean?
  • Ist es eine gute Idee, die Geschäftslogik in die Aktionsmethoden zu schreiben? Ich habe Hunderte von Zeilen in Aktionsmethoden geschrieben gesehen.
  • Glauben Sie, dass wir in den Getter-Methoden irgendeine Logik schreiben können? Wie oft Getter oder Setter im JSF-Lebenszyklus aufgerufen wurden.
  • Was ist die konventionelle Art, die faces-config.xml zu schreiben? Ich habe in einem Dokument gelesen, dass es gute Praxis ist, die Bean-Deklaration und den Navigationsfall für diese Bean zusammen zu schreiben. Es wird besser lesbar sein.
  • Das Schreiben des Phasen-Listeners würde die Antwortzeit beeinflussen. Zum Beispiel schreibe ich eine Logik, um den Anforderungsparameter im Phasenlistener zu analysieren und einige Logik zu machen. Gibt es dazu einen Rat?

Bitte beantworten Sie die obigen Fragen. Wenn mir die Antwort klar ist, werde ich weitere Fragen stellen.

    
Krishna 21.01.2011, 04:14
quelle

2 Antworten

15

Beachten Sie, dass obwohl Sie [icefaces] getaggt haben, diese Antwort auf JSF im Allgemeinen und nicht auf IceFaces angewendet wird.

  

Was ist im MVC-Muster eine Modellkomponente im JSF? Ist es die Managed Bean?

Das ist richtig. Die Ansicht ist die JSP / Facelets-Seite. Der Controller ist der FacesServlet . Für weitere Details darüber, wie es "unter der Decke" funktioniert, siehe auch diese Antwort .

  

Ist es eine gute Idee, die Geschäftslogik in die Aktionsmethoden zu schreiben? Ich habe Hunderte von Zeilen in Aktionsmethoden geschrieben gesehen.

Sie können den Anruf auch an einen Geschäftsdienst wie ein EJB delegieren. Auf diese Weise können Sie die Geschäftsdetails abstrahieren. In "einfachen" Anwendungen ist es normalerweise nicht schädlich, dieses Teil wegzulassen und alles in der verwalteten Bean zu tun. Sobald Sie jedoch an einem Punkt angelangt sind, an dem Sie die Geschäftslogik ändern möchten (z. B. für einen anderen Kunden oder für Demozwecke usw.), wäre es einfacher, einen Service zu haben, so dass Sie den verwalteten Service nicht ändern müssen Beans, aber Sie müssen nur eine andere Implementierungsklasse einer bestimmten Business-Schnittstelle schreiben.

  

Denkst du, dass wir irgendeine Logik in die Getter-Methoden schreiben können ?. Wie oft Getter oder Setter im JSF-Lebenszyklus aufgerufen wurden.

Wenn die Geschäftslogik benötigt ist, um bei jedem Getter-Aufruf ausgeführt zu werden, dann tun Sie dies (dies ist jedoch in der realen Welt sehr unwahrscheinlich, erwarten Sie eine wahnsinnige Protokollierung oder spezielle faule (Neu-) Ladefälle). Wenn die Geschäftslogik jedoch nur einmal pro Aktion, Ereignis, Anforderung, Sitzung oder Anwendungsumfang ausgeführt werden muss, muss sie unbedingt an anderer Stelle ausgeführt werden. Siehe auch diese Antwort .

Wie oft ein Getter gerufen wird, sollte Ihre geringste Sorge sein. Der Getter sollte nichts anderes tun als die fragliche Immobilie zurückzugeben. Wenn der Ausgabewert aufgerufen wird, kann er einmal pro Anfrage sein. Wenn der Eingabewert aufgerufen wird, kann er zweimal pro Anforderung angegeben werden. Wenn Sie sich innerhalb einer Datentabelle / Wiederholungskomponente befinden, multiplizieren Sie die Aufrufe mit der Anzahl der Zeilen. Innerhalb der gerenderten Attribute multiplizieren Sie die Aufrufe mit 6-8 mal.

  

Was ist die herkömmliche Art, die faces-config.xml zu schreiben? Ich habe in einem Dokument gelesen, dass es gute Praxis ist, die Bean-Deklaration und den Navigationsfall für diese Bean zusammen zu schreiben. Es wird lesbarer sein.

Ich selbst benutze sehr selten Navigationsfälle, normalerweise gibt es keine in meinem faces-config.xml . Ich poste immer zurück zur gleichen Ansicht (return null oder void und dann render / include das Ergebnis bedingt. Für die Seite-zu-Seite-Navigation verwende ich keine POST-Anfragen (für welche Navigationsfälle obligatorisch sind) einfach weil das ist einfach schlecht für UX (User eXperience; Browser-Zurück-Button verhält sich nicht so wie es sollte und URLs in der Browser-Adressleiste sind immer einen Schritt zurück, weil sie standardmäßig vorwärts sind, keine Weiterleitungen) und SEO (Search Engine Optimization; searchbots doesn ' t Index-POST-Anfragen). Ich verwende einfach Ausgangslinks oder sogar einfache HTML <a> -Elemente für die Navigation von Seite zu Seite.

Auch in JSF 2.0 sind in faces-config.xml keine verwalteten Bean-Definitionen und Navigationsfälle erforderlich. Siehe auch diese Antwort .

  

Das Schreiben des Phasen-Listeners würde die Antwortzeit beeinflussen. Zum Beispiel schreibe ich eine Logik, um den Anforderungsparameter im Phasenlistener zu analysieren und einige Logik zu machen. Gibt es dazu einen Rat?

Dies ist wie bei Servlet-Filtern in der Kategorie der vorzeitigen Optimierung. Sich um ihre Leistung zu sorgen macht normalerweise keinen Sinn. Dies ist pro Saldo in der Regel nur ein oder zwei Zeilen Code extra. Wirklich nichts, worüber man sich Sorgen machen müsste. Sie hätten viel größere Probleme, wenn Sie diesen Code über alle Klassen hinweg kopieren. Wenn Sie wirklich denken, dass es Leistung kostet, profilieren Sie es zuerst und dann können wir darüber sprechen.

    
BalusC 21.01.2011, 11:33
quelle
4

Was ist im MVC-Muster eine Modellkomponente im JSF? Ist es die Managed Bean?

Ich schlage das vor:

VIEW LAYER (besteht aus einem Mini MVC):

userForm.xhtml & lt; - view; die Webseite

UserController & lt; - Controller; eine verwaltete Bean

UserController.get / setUser & lt; - Modell; das Modell für die Ansicht

Controller-Schicht:

UserService & lt; - Controller; der Controller, der CRUD-bezogene Geschäftslogik enthält

UserDAO & lt; - speichert Objekte in der Datenbank

Benutzer & lt; - das Domänenobjekt, das dauerhaft erhalten wird

MODELLSCHICHT:

Die Datenbank

Ist es eine gute Idee, die Geschäftslogik in die Aktionsmethoden zu schreiben? Ich habe Hunderte von Zeilen in Aktionsmethoden geschrieben gesehen.

Fügen Sie in meinem Beispiel die Geschäftslogik in die Methoden des UserService ein. Die Aktionsmethode von UserController führt nicht viel mehr aus, als die Methode im UserService aufzurufen, alle Ausnahmen abzufangen und die Antwort für die nächste angezeigte Webseite zu formatieren.

Denkst du, dass wir irgendeine Logik in die Getter-Methoden schreiben können ?. Wie oft Getter oder Setter im JSF-Lebenszyklus aufgerufen wurden.

Bevorzugt für Getter / Setter, nur das Holen / Einstellen zu tun. Keine Logik.

Was ist die konventionelle Art, faces-config.xml zu schreiben? Ich habe in einem Dokument gelesen, dass es gute Praxis ist, die Bean-Deklaration und den Navigationsfall für diese Bean zusammen zu schreiben. Es wird lesbarer sein.

Ich deklariere alle meine verwalteten Bohnen zusammen. Und deklariere alle meine Navigationsregeln zusammen.

Das Schreiben des Phasen-Listeners würde die Antwortzeit beeinflussen. Zum Beispiel schreibe ich eine Logik, um den Anforderungsparameter im Phasenlistener zu analysieren und einige Logik zu machen. Gibt es dazu einen Rat?

Sie sind sich nicht sicher, was Sie genau machen, aber Sie sollten Request-Parameter nicht manuell analysieren müssen. JSF sollte die Werte Ihres Formulars direkt in das Modell der Ansicht für Sie einspeisen. Vielleicht brauche ich mehr Informationen über das, was Sie versuchen zu tun.

Hoffe, das hilft.

    
Robert Hume 21.01.2011 04:32
quelle

Tags und Links