Model-View-Controller für Web-Anwendungen

MVC steht für Model-View-Controller und ist ein sog. Design Pattern (Entwurfsmuster) für objektorientierte Client-Server-Anwendungen. Mit anderen Worten MVC ist eine Architektur für eine Anwendung; d.h. ein grundsätzlicher Plan, aus welchen wesentlichen Teilen die Anwendung bestehen soll und wie diese Teile im Prinzip zusammenarbeiten sollen.

MVC ist schon recht alt, es kam erstmals mit der Verbreitung von Smalltalk (1980) auf. Für Web-Anwendungen, bei denen die Kommunikation zwischen Web-Browser und Web-Server "stateless" vor sich geht, hat man eine Variante von MVC, das sog. MVC Model 2 entwickelt.

Abbildung: MVC Model 2

Der Controller erhält die Benutzer-Eingaben (HTTP-Request) und muss entscheiden, was damit zu tun ist ("dispatchen"). D.h. er instanziiert das erforderliche ModelBean und übergibt ihm die Benutzer-Eingaben vermittels der Setter-Methoden. Danach ruft der Controller die erforderliche View-Page auf. Typischerweise wird der Controller als ein Servlet realisiert.

Das Model enthält die eigentliche Geschäftslogik und verwaltet die dazu erforderlichen persistenten Geschäftsdaten. Typischerweise wird es in der Technik eines Beans (JavaBean) realisiert. Ergebnisdaten werden durch Getter-Methoden der Aussenwelt zur Verfügung gestellt. Es findet keine (HTML-)Formatierung statt, das macht die getrennte View-Page.

Der View wird typischerweise als JavaServer Page (JSP) realisiert und holt sich per Getter-Methoden die Ergebnisdaten vom ModelBean und bereitet sie als HTML-Seite (Form) auf. Durch das Betätigen des Submit-Buttons auf der Form wird erneut der Controller aktiviert.

Sinn der MVC-Architektur ist es, bei grösseren Web-Anwendungen Änderungsfreundlichkeit zu erreichen, durch die Entkopplung von Benutzerschnittstelle, Geschäftslogik und Daten. Durch diese Trennung ist es auch möglich, Aufgaben, die ganz unterschiedliche Skills erfordern wie Java-Geschäftlogik und HTML-Benutzeroberfläche unterschiedlichen Teams zuzuordnen.

Hintergrund: Servlets und JavaServer Pages

Servlets waren die erste Möglichkeit, mit Hilfe von Java-Code auf einem Server (mit Servlet-Engine) dynamisch HTML-Seiten zu erzeugen und an den Browser zu schicken. Grosse Teile das Java-Codes beschäftigen sich dann mit HTML....

JavaServer Pages (JSP) machten einem das Leben leichter. Man kann in HTML-Seiten einfach ein bisschen Java-Code rein mixen - ähnlich wie Microsofts Active Server Pages (ASP) und auch ähnlich wie PHP.

Bei Servlets hat man eine Menge HTML im Java-Code, nun mit JSP hat man eine Menge Java-Code in der HTML-Datei. So gesehen hat man noch nicht viel erreicht, ausser dass man HTML-Entwicklern nun ermöglicht, auf einfache Art gleich noch Java-Code zu schreiben.

Sinnvoll wird das Ganze erst, wenn man den meisten Java-Code wieder aus der JavaServer Page auslagert (Mehr-Seiten-Ansatz) als JavaBean und dann nur noch über sog. JSP-Tags anspricht.

Ein einfacher Ein-Seiten-Ansatz, ohne ein sauberes Architektur-Konzept (MVC), hat folgende Probleme:

• Heavy HTML and Java coupling
  The coder of the JSP file must be both a page designer and a Java developer. The result is often either terrible Java code or an ugly page, or sometimes both.
• Java and JavaScript blur
  As the pages become larger, there can be a tendency to implement some JavaScript. When the JavaScript appears in a page, the script can get confused with the Java code. An example of a possible point of confusion is using client-side JavaScript to validate the email field.
• Embedded flow logic
  To understand the entire flow of the application, you have to navigate all of the pages. Imagine the spaghetti logic on a 100-page Web site.
• Debugging difficulties
  In addition to being ugly to look at, HTML tags, Java code, and JavaScript code all in one page makes it difficult to debug problems.
• Tight coupling
  Changes to business logic or data means possibly touching every page involved.
• Aesthetics
  Visually, in large pages, this type of coding looks messy. When I was doing Microsoft ASP development, I would commonly see 1000-line pages. Even with syntax coloring, it was still difficult to read and understand.
  

[Home]  [Neuigkeiten] [Bildung]  [Labor] [Beruf]  [Freizeit] [Mindmaps]