MVC

Eine oft aufgeworfene Frage ist welche Teile Model, View und Controller in JSF repräsentieren. Nachdem ich schon einige unterschiedliche Meinungen zu diesem Thema gelesen habe, zeige ich hier die auf dieser Seite verwendete Aufteilung und Namens Konvention.

Konvention

Zuerst einmal die Erklärung einiger wichtiger Begriffe:

Java Bean

Wiederverwendbare Software Komponente die ohne Programmierung konfiguriert werden kann

Managed Bean

Registrierte Java Bean die automatisch erstellt und initialisiert wird

Backing Bean

Beliebige Bean die Attribute und Komponenten für eine Web Form bereitstellt

Eine Bean kann Managed Bean und zugleich Backing Bean sein, wenn es in Faces Config registriert ist und zusätzlich bsw Style Class Informationen bereitstellt.

Model

Das Model enthält POJO Klassen, die einfach nur die Daten speichern, die in der View benötigt werden. Für diese Klassen benutze ich kein Suffix, wodurch es lesbarer in den JSF Seiten wird.

Paket:

de.icoding.model.forum

Klassen:

Forum, ForumEntry

Für die Verwaltung von Stammdaten verwende ich meistens zwei Klassen:

Forum:

Enthält alle Entity Daten, wird für Neuanlage/Änderung verwendet

ForumEntry:

Repräsentiert ein List Entity, enthält nur die wesentlichsten Daten

View

Die View besteht aus der JSF Seite inklusive der Komponenten und den Backing Beans, die View bezogenen Code zur Steuerung der Komponenten enthalten. Für diese Klassen habe ich das Suffix View gewählt, da es in den Seiten lesbarer als Backing ist.

Paket:

de.icoding.view.forum

Klassen:

ForumView, ForumListView, ForumListViewEntry

Für die Verwaltung von Stammdaten verwende ich meistens drei Klassen:

ForumView:

Detail View um einzelne Entity anzulegen oder zu ändern

ForumListView:

Auflisten von Enities

ForumListViewEntry:

Einzelnes List Entity

Controller

Der Controller Teil wird von verschiedenen Klassen wie Filter, JSF Servlet, ViewHandler und auch der Business Logik durchgeführt.

Paket:

de.icoding.controller

Klassen:

ServiceFilter, ViewHandler

Die Business Logik ist getrennt aber gehört auch zum Controller, weil die Logik Methoden mit speziellen IDs die Navigation steuern. Für diese Klassen verwende ich das Suffix Action.

Paket:

de.icoding.action.forum

Klassen:

ForumAction

Best Practice

View

Am besten ist es man erstellt für alle JSF Seiten mit dynamischen Content auch gleich eine dazugehörige View Bean. Somit hat man in der ganzen Applikation eine einheitliche Struktur und kann auch schnell mal eine Backing Methode einfügen.

Bei einer Seite mit Formular wird einfach die ganze View Bean als Managed Bean registriert und in der verarbeitenden Action Methode mit dieser einen Klasse, die alle Model Referenzen enthält, gearbeitet.

Alle View Beans sind von der Klasse BasicView abgeleitet, die allgemeine Methoden zur Verfügung stellt, die von allen JSF Seiten genutzt werden.

Für JSF Seiten mit statischen Content Teil, also bsw. ein Impressum mit hart codierten Firmendaten, wird keine eigene View Klasse programmiert, sondern nur die Basic View genutzt.

Controller

Normallerweise braucht man keine extra Controller Klasse für eine View zu programmieren. Das JSF Framework übernimmt ja bereits Prüfung und Aktualsierung der Model Daten. Eigene Validator und Converter würde ich als Erweiterung des Frameworks sehen.

Eine Ausnahme könnte sein, wenn aufgrund einer Benutzer Aktion die Daten des Model speziell abgeändert werden sollen und man dies nicht in der Action Klasse codieren möchte um es von der Business Logik zu trennen.

Johannes Hammoud MVC 08.11.2008