Model View Controller in JSF – wo und was ist der Controller?
Das Model View Controller (MVC) Pattern ist wohl eines der bekanntesten Architekturmuster. So ziemlich jeder Informatiker muss sich damit auseinandersetzen und nicht selten ist es für Berufsanfänger auch eine Frage im Bewerbungsgespräch. Unterhält man sich mit verschiedensten, auch schon sehr erfahrenen, Leuten darüber ist es dennoch erstaunlich wie viele unterschiedliche Auslegungen es dazu gibt.
Vor allem bei der Frage was denn der Controller, gerade bei Web-Frameworks, sei gehen die Meinungen oft auseinander. Während man z.b. FAT Client Anwendungen den Controller oft direkt als erstes schreibt und diesen dadurch sehr genau bestimmen kann gehen die Meinungen was denn der Controller in JSF Anwendungen ist deutlich auseinander. Für JSF Anwendungen geht z.B. unter anderem die Meinung um, dass die Managed Bean (oder bei Verwendung von Seam eine Seam Action / Spring eine Spring Bean) der Controller ist. Auch die Aussage, dass die JSP/JSF/XHTML Seite oder der Browser der Controller ist (denn der Controller nimmt laut Definition die Eingaben entgegen und leitet sie weiter) waren darunter.
Nun bin ich bei Recherchen zu Seam über eine Präsentation von Roi Aldaag gestolpert und habe dabei folgende, meiner Meinung nach wirklich passende, MVC Beschreibung für JSF gesehen:
Man sieht darin, dass der Controller in einer JSF Anwendung aus mehreren Teilen besteht. Zum einen das FacesServlet, welches jeden Request entgegennimmt und initial verarbeitet. Je nach Situation wird anschließend die faces-config.xml verwendet um an das Model weiterzuleiten oder die in JSF möglichen Event Listener oder Action Handler aufgerufen.
Somit besteht der Controller aus drei Teilen:
- Front-Servlet (
FacesServlet) - Konfiguration (
faces-config.xmloderpages.xmlin Seam Anwendungen) - Event Listener (z.B. ValueChangeListener)
- Action Event (ausgelöst durch
h:commandButtonundh:commandLinkActions)
Gerade das in JSF vorhandene Event Modell sowie die Action Events bringen JSF noch viel näher an das MVC Pattern als die bisherigen Web-Frameworks.
Nur der Vollständigkeit halber im folgenden noch eine kurze Erläuterung zu den Teilen Model und View:
Die View in einer JSF Anwendung beinhaltet:
- Component Tree (JSF Komponentenbaum)
- Component Model (Java Beans als Unterstützung für Komponenten)
- Delegates (Konverter, Validator oder Renderer)
- Resources (JSP, XML, Properties)
Das Model im MVC ist nicht ausschließlich das Domain Model oder Entity Modell gemeint. Mit Modell meint man die komplette Business Logik in einer Anwendung:
- Pojos (bei Plain JSF / Seam Pojo Anwendung)
- EJB, Entity Beans (bei einer JEE Anwendung)
Der Screenshot der MVC Umsetzung in einer JSF Anwendung ist aus der folgenden Präsentation mit dem Titel “JSF and Seam”:
Obwohl das Thema wohl wirklich ein alter Hut ist und der ein oder andere es wohl schon zum xten mal durchgekaut hat fand ich es wichtig MVC im Rahmen von JSF noch einmal aufzuzeigen ohne direkte Widerrede zu erhalten ;). In Meetings und persönlichen Diskussionen darüber brechen wir meistens ab da man sich doch nicht einigen kann, die Meinungen weit auseinander gehen und die Gemüter am Ende sehr erhitzt sind. Also falls jemand eine ergänzende oder gar total andere Meinung zu MVC hat darf er sich in den Kommentaren auslassen – es wird nichts zensiert ;).
Wenn du Fragen oder Anregungen zum Post hast, dann hinterlasse doch einen Kommentar oder wenn du weiterhin Artikel von Javathreads lesen möchtest, dann abonniere den RSS Feed und sehe direkt in deinem Feed Reader die nächsten Artikel.
Ähnliche Artikel, die dich interessieren könnten:
Kommentare
Hi William,
die Java Beans die direkt zu JSF Komponenten gehören (die keine unmanaged Backing Beans sind) gehören nicht zu deiner Business Anwendung sondern beziehen sich nur auf eine GUI Komponenten wie z.B. ein Button oder eine Tabelle. Sie schreiben z.B. die notwendigen HTML Elemente raus oder helfen über einer Liste zu iterieren um die Tabelle korrekt darzustellen. Letztlich haben sie aber überhaupt nichts mit deinem Model (Business Anwendung) zu tun sondern unterstützen nur die Komponenten in der View bezüglich der Darstellung. Aus diesem Grund werden diese Java Beans der View zugeordnet.
Ein sehr guter Artikel zum Verständnis des JSF Component Model ist auch in der Reihe JSF for nonbelievers von IBM zu finden: http://www.ibm.com/developerworks/java/library/j-jsf4/
Hallo Markus,
netter Blog!
Das Bild ist richtig, aber auch irgendwie falsch, weil:
Wenn ich die verfügbaren JSF Beispiele im Web so angucke, sieht man, dass ein Großteil der Anwendundsfunktionalität in Managed Beans stattfindet, insbesondere werden dort auch Actionen, ActionListener ausprogrammiert. Ebenso kann man dort auch Standard JSF UI Komponenten erweitern, wenn man nicht gleich eigene entwickeln möchte.
Heißt für mich: die mBeans sind in der Praxis mal Model, mal View, mal Controller. Insofern ist das obige Bild zwar richtig, aber entspricht m.E. nicht dem, was man an Anwendungsdesign wirklich hat.
VG
Bernd
Hi Markus,
ist es möglich z.B. in der BeforePhase-Methode eines PhaseListeners den Namen der Backing Bean, sowie die aufgerufene ActionMethode herauszufinden?
Somit könnte man allgemein alle ActionMethoden-Aufrufe Loggen. Eine Art Aspect Programmierung.
Hast du vielleicht damit Erfahrung?
Hallo,
das Bild ist in meinen Augen ebenfalls nicht falsch, aber auch nicht 100% korrekt. ManagedBeans werden sowohl als Controller als auch als Model eingesetzt.
Gruß
Guido
hallo Markus,
bezüglich der Skizze habe ich eine Frage: dass einerseits die managed Beans(also von JSF gemanaged backing Beans) zu dem Model gehört ist klar, aber warum gehört das Component Model(also unmanaged Backing Beans) zum View?