4. MVC-Entwicklung (Model–View–Controller)

Eine Webanwendung verfügt oft über eine 3-Schichten-Architektur:

Die [DAO]-Schicht übernimmt den Datenzugriff, meist auf persistente Daten innerhalb eines DBMS. Es kann sich dabei aber auch um Daten handeln, die von Sensoren, dem Netzwerk usw. stammen.
Die [Business]-Schicht implementiert die „Geschäftslogik“-Algorithmen der Anwendung. Diese Schicht ist unabhängig von jeglicher Form der Benutzeroberfläche. Daher muss sie mit einer Konsolenoberfläche, einer Weboberfläche oder einer Rich-Client-Oberfläche nutzbar sein. Sie muss daher außerhalb der Weboberfläche testbar sein, insbesondere mit einer Konsolenoberfläche. Dies ist in der Regel die stabilste Schicht der Architektur. Sie ändert sich nicht, wenn die Benutzeroberfläche oder die Methode für den Zugriff auf die für den Betrieb der Anwendung erforderlichen Daten geändert wird.
Die [Benutzeroberfläche]-Ebene, also die (oft grafische) Schnittstelle, über die der Benutzer die Anwendung steuern und Informationen von ihr erhalten kann.

Die Kommunikation verläuft von links nach rechts:

Der Benutzer sendet eine Anfrage an die [Benutzeroberfläche]-Schicht
diese Anfrage wird von der [Benutzeroberfläche]-Schicht formatiert und an die [Geschäftslogik]-Schicht weitergeleitet
Wenn die [Geschäftslogik]-Schicht Daten benötigt, um diese Anfrage zu bearbeiten, fordert sie diese von der [DAO]-Schicht an
jede abgefragte Schicht sendet ihre Antwort an die links davon liegende Schicht zurück, bis die endgültige Antwort den Benutzer erreicht.

Der Zugriff auf die [Business]- und [DAO]-Schichten erfolgt normalerweise über Java-Schnittstellen. Somit kennt die [Business]-Schicht nur die Schnittstelle(n) der [DAO]-Schicht und weiß nichts von den Klassen, die diese implementieren. Dies gewährleistet die Unabhängigkeit der Schichten voneinander: Eine Änderung der Implementierung der [DAO]-Schicht hat keine Auswirkungen auf die [Business]-Schicht, solange die Definition der Schnittstelle der [DAO]-Schicht unverändert bleibt. Dasselbe gilt für die [Benutzeroberfläche]- und die [Business]-Schicht.

Die MVC-Architektur (Model–View–Controller) wird in der [Benutzeroberfläche]-Schicht implementiert, wenn es sich um eine Webschnittstelle handelt:

Die Verarbeitung einer Client-Anfrage erfolgt in folgenden Schritten:

Der Client sendet eine Anfrage an den Controller. Der Controller verarbeitet alle Client-Anfragen. Er ist der Einstiegspunkt der Anwendung. Er ist das C in MVC.
Der C-Controller verarbeitet diese Anfrage. Dazu benötigt er möglicherweise Unterstützung durch die Geschäftslogik. Sobald die Client-Anfrage verarbeitet wurde, kann sie verschiedene Antworten auslösen. Ein klassisches Beispiel ist:
- eine Fehlerseite, wenn die Anfrage nicht korrekt verarbeitet werden konnte
- ansonsten eine Bestätigungsseite
Der Controller wählt die Antwort (= Ansicht) aus, die an den Client gesendet werden soll. Die Auswahl der an den Client zu sendenden Antwort umfasst mehrere Schritte:
- Auswahl des Objekts, das die Antwort generiert. Dies wird als View (V) bezeichnet, das V in MVC. Diese Wahl hängt in der Regel vom Ergebnis der Ausführung der vom Benutzer angeforderten Aktion ab.
- die Bereitstellung der Daten, die zur Generierung dieser Antwort benötigt werden. Tatsächlich enthält diese Antwort meist Informationen, die vom Controller berechnet wurden. Diese Informationen bilden das sogenannte M-Modell der Ansicht, das M in MVC.
- Schritt 3 besteht also darin, eine Ansicht (V) auszuwählen und das dafür erforderliche Modell (M) zu erstellen.
Der Controller C weist die ausgewählte Ansicht an, sich anzuzeigen. Dies beinhaltet in der Regel die Ausführung einer bestimmten Methode der Ansicht V, die für die Generierung der Antwort an den Client zuständig ist. In diesem Dokument bezeichnen wir sowohl das Objekt, das die Antwort an den Client generiert, als auch die Antwort selbst als Ansicht. Die MVC-Literatur ist in diesem Punkt nicht eindeutig. Würde man die Antwort als Ansicht bezeichnen, könnte man das Objekt, das diese Antwort generiert, als Ansichtsgenerator bezeichnen.
Der View-Generator V verwendet das vom Controller C vorbereitete Modell M, um die dynamischen Teile der Antwort zu initialisieren, die er an den Client senden muss.
Die Antwort wird an den Client gesendet. Ihre genaue Form hängt vom View-Generator ab. Es kann sich um einen HTML-Stream, eine PDF-Datei, eine Excel-Datei usw. handeln.

Die MVC-Webentwicklungsmethodik erfordert nicht zwangsläufig externe Tools. Somit kann eine Java-Webanwendung mit MVC-Architektur unter Verwendung eines einfachen JDK und grundlegender Webentwicklungsbibliotheken entwickelt werden. Eine für einfache Anwendungen geeignete Vorgehensweise ist wie folgt:

Der Controller wird von einem einzigen Servlet abgewickelt. Dies ist das C in MVC.
Alle Client-Anfragen enthalten ein „action“-Attribut, zum Beispiel (http://.../appli?action=liste).
Je nach Wert des „action“-Attributs führt das Servlet eine interne Methode vom Typ [doAction(...)] aus.
Die Methode [doAction] führt die vom Benutzer angeforderte Aktion aus. Dazu nutzt sie bei Bedarf die [Business]-Schicht.
Je nach Ergebnis der Ausführung entscheidet die [doAction]-Methode, welche JSP-Seite angezeigt werden soll. Dies ist die View (V) im MVC-Modell.
Die JSP-Seite enthält dynamische Elemente, die vom Servlet bereitgestellt werden müssen. Die [doAction]-Methode stellt diese Elemente bereit. Dies ist das View-Modell, das M in MVC. Dieses Modell wird meist im Request-Kontext (request.setAttribute("key", "value")) oder, seltener, im Session- oder Application-Kontext abgelegt. Eine JSP-Seite hat Zugriff auf diese drei Kontexte.
Die Methode [doAction] rendert die Ansicht, indem sie den Ausführungsfluss an die ausgewählte JSP-Seite übergibt. Dazu verwendet sie eine Anweisung wie [getServletContext() .getRequestDispatcher("JSP-Seite").forward(request, response)].

Dieses MVC-Entwurfsmuster wird als „Front-Controller“-Muster oder Single-Controller-Muster bezeichnet. Ein einziges Servlet verarbeitet alle Anfragen aller Benutzer.

Kehren wir zur Architektur der vorherigen Webanwendung zurück:

Diese Architektur entspricht der folgenden n-Tier-Architektur:

Es gibt eigentlich nur eine Schicht: die Webschnittstellenschicht. Im Allgemeinen weist eine auf Servlets und JSP-Seiten basierende MVC-Webanwendung die folgende Architektur auf:

Für einfache Anwendungen ist diese Architektur ausreichend. Wenn Sie mehrere Anwendungen dieser Art geschrieben haben, werden Sie feststellen, dass die Servlets zweier verschiedener Anwendungen

denselben Mechanismus verwenden, um zu bestimmen, welche Methode [doAction] ausgeführt werden soll, um die vom Benutzer angeforderte Aktion zu bearbeiten
sich tatsächlich nur im Inhalt dieser [doAction]-Methoden unterscheiden

Die Versuchung ist dann groß,

die Verarbeitung (1) in ein generisches Servlet auszulagern, das keine Kenntnis von der Anwendung hat, die es verwendet
die Verarbeitung (2) an externe Klassen zu delegieren, da das generische Servlet nicht weiß, in welcher Anwendung es verwendet wird
die vom Benutzer angeforderte Aktion über eine Konfigurationsdatei mit der Klasse zu verknüpfen, die sie verarbeiten muss

Es sind Werkzeuge, oft als „Frameworks“ bezeichnet, entstanden, um Entwicklern diese Möglichkeiten zu bieten. Das älteste und wahrscheinlich bekannteste davon ist Struts (http://struts.apache.org/). Jakarta Struts ist ein Projekt der Apache Software Foundation (www.apache.org). Dieses Framework wird unter (http://tahe.developpez.com/java/struts/) beschrieben.

Das Spring-Framework (http://www.springframework.org/), das erst kürzlich erschien, bietet ähnliche Funktionen wie Struts. Seine Verwendung wurde in mehreren Artikeln beschrieben (http://tahe.developpez.com/java/springmvc-part1/).

Wir stellen nun ein Beispiel für eine MVC-Architektur vor, die auf Servlets und JSP-Seiten basiert.