Struts
aus Wikipedia, der freien Enzyklopädie
Struts ist ein Open-Source-Framework für die Präsentationsschicht von Java-Webanwendungen. Als eines der bekanntesten Jakarta-Projekte ist es im Jahr 2005 zu einem „Apache Toplevel Project“ avanciert. Struts beschleunigt die Entwicklung von Webanwendungen wesentlich, indem es HTTP-Anfragen in einem standardisierten Prozess verarbeitet. Dabei bedient es sich standardisierter Technologien wie JavaServlets, Java Beans, Resource Bundles und XML sowie verschiedener Jakarta-Commons-Pakete.
Für den Entwickler bedeutet das, dass viele applikationsrelevante Funktionen bereits implementiert und einsatzbereit sind. Struts wird bereits in sehr vielen Webanwendungen eingesetzt und gemeinhin als solides Framework angesehen. Struts wurde von Craig McClanahan [1] im Jahr 2000 entwickelt. Seitdem arbeitet eine ständig wachsende Entwicklergemeinde an der Verbesserung des Frameworks. Die aktuelle Version ist 2.0.
Neueste Bemühungen zielen darauf das Struts Framework mit dem WebWork Framework als Struts Ti zu verschmelzen, die Modularität des monolithischen Struts weiter voranzutreiben und mit der Komponente Shale einen Anker hin zu JavaServer Faces zu schlagen.
Es gibt auch eine alternative Version des Struts-Frameworks, welche auf Basis der Skriptsprache PHP 5 implementiert wurde: struts4php.
Inhaltsverzeichnis |
[Bearbeiten] Aufbau
Das Struts-Framework basiert auf dem Paradigma des Model-View-Controllers. Dabei sind die Komponenten von Struts in der View und dem Controller anzusiedeln. Typische Model-Funktionalitäten bietet das Framework nicht. Das Framework beinhaltet zurzeit ca. 300 Java-Klassen, die in acht Kernpakete eingeteilt sind.
[Bearbeiten] Theoretischer Ansatz
[Bearbeiten] Model-1-Architektur mit JavaServlets/JSP
Nachdem die Technologie von Java-Servlets eingeführt wurde, erkannte man schnell, dass das Erstellen von HTML-Seiten mit Servlets zeitaufwendig und die Weiterentwicklung von Views sehr mühsam sein kann. Hinzu kam, dass alle drei Komponenten des MVC in einem Servlet realisiert wurden. Daraufhin wurde die JSP-Technologie eingeführt, die vor allem dem Webdesigner die Arbeit leichter machte und sich in kurzer Zeit durchsetzte. Daraus entwickelte sich die Model-1-Architektur, die beschreibt, dass Datenhaltung, Geschäftslogik und View in einer JSP anzusiedeln sind, was jedoch bei komplexer Anwendungslogik zu neuen Problemen führt: Die JSP wird in kürzester Zeit unüberschaubar und lässt sich nur durch Entwickler warten, die sowohl HTML- als auch Java-Kenntnisse besitzen. Zwar mildert die Verwendung von Tag-Bibliotheken wie z. B. JSTL, dieses Problem etwas, weil kein Java-Code mehr benötigt wird, das konzeptionelle Grundproblem der Vermischung von Präsentation mit fachlicher Funktionalität bleibt jedoch bestehen.
[Bearbeiten] Model-2-Architektur mit Struts
Die aufgeführten Problematiken haben dazu beigetragen, dass man ein neues Konzept entwickeln musste, das die einzelnen Komponenten klarer voneinander abgrenzt und Java-Servlets und JSP gleichermaßen einbindet. Es entstand die Model-2-Architektur für Webanwendungen, die ihren Einsatz im Struts-Framework gefunden hat. Eine wichtige Rolle spielt hierbei das ActionFirst Pattern. Das bedeutet, dass View-Komponenten, die durch JSP abgebildet werden, ausschließlich über Struts-Actions (Servlets) referenziert werden, niemals über einen HTTP-Request. Dabei wird jeder HTTP-Request von einer Controller-Komponente (Servlet) entgegengenommen, bei Struts dem so genannten ActionServlet. Nach einem vom Benutzer initiierten HTTP-Request wird eine Struts-Action ausgeführt, die eine Verbindung zur Geschäftslogik herstellt und diese aktualisiert. Die Ergebnisse der Ausführung werden anschließend in dem HTTP-Request als Attribute abgelegt. Danach wird über einen Action-Forward die View aufgerufen und mit den im HTTP-Request abgelegten Daten gefüllt. Befindet sich in einer View-Komponente ein HTML-Formular, so wird dieses über eine JavaBean mit Werten aus dem Modell gefüllt. Die Model-2-Architektur bietet sich hier als Regelwerk an (u.a. ist die Kommunikation von Views untereinander, wie auch die feste Kodierung von Flusssteuerung in JSP, verboten).
[Bearbeiten] Praktische Umsetzung
Ziel: Trennung von Präsentation, Datenhaltung und Anwendungslogik. Dies erhöht die Übersicht und die Wartbarkeit. Deshalb definiert man in Struts drei Hauptkomponenten:
- JSP: Präsentation. Wird zur Laufzeit in ein Servlet (Java-Code) umgewandelt und kompiliert.
- Action: Controller. Schnittstelle zwischen View und Anwendungslogik (Holen und Aktualisieren der Daten).
- FormBean: Datenhaltung und Validierung (Inhalte von HTML-Formularfeldern, Kollektionen für Listen usw. in Java Beans).
Alle drei Komponenten werden in der zentralen Konfigurationsdatei von Struts (struts-config.xml) miteinander verknüpft und können somit miteinander kommunizieren.
Beispiel:
<struts-config>
<form-beans type="org.apache.struts.action.ActionFormBean">
<form-bean name="RegisterForm" type="bar.foo.web.RegisterForm" />
</form-beans>
<action-mappings type="org.apache.struts.action.ActionMapping">
<action path="register"
name="RegisterForm"
type="bar.foo.web.RegisterAction"
input="/web/register.jsp"
scope="request"
validate="true">
<forward name="success" path="/home.do" />
<forward name="failure" path="/error.do" />
</action>
</action-mappings>
</struts-config>
Hier wurden register.jsp, RegisterAction, RegisterForm verknüpft.
[Bearbeiten] Die Präsentation
Ein Paradigma ist, in der JSP so wenig Java-Code (Scriptlets) wie möglich zu verwenden. Um dies zu ermöglichen, sollte man die von Struts mitgelieferten Tag-Libs einsetzen, die einem beim Auslesen der Form-Bean helfen. Geschrieben und gelesen wird hier jeweils nur aus der im Request liegenden Form-Bean.
Beispiel:
<html:text name="RegisterForm" property="emailAddress" size="20"/>
Hier wird das Attribut "emailAddress" der Form-Bean "RegisterForm" über seine Setter-Methode nach dem Senden des Formulars mit dem Inhalt des Textfeldes gefüllt. Weiterhin wird ein <input type="text" size="20" name="emailAddress" value="..."/> HTML-Element in der JSP generiert.
[Bearbeiten] Tiles
Struts besitzt ebenfalls eine Template-Erweiterung, Tiles genannt. Sie ermöglichen dem Entwickler, seine Webseiten komponentenbasiert aufzubauen (Header, Footer, Content usw.). Tiles geht dabei weit über das statische Inkludieren von JSP-Inhalten hinaus. So können Tiles weitere Tiles inkludieren, wohingegen einfache JSP-Inkludierungen nur JSP-Seiten einbeziehen können.
[Bearbeiten] Validator
Seit der Version 1.1 besitzt Struts ein Validierungswerkzeug, das dem Entwickler bei der Überprüfung der abgesendeten Formdaten hilft. Es arbeitet mit so genannten Validators, die eine spezifische Prüfaufgabe durchführen und beliebig wiederverwendet werden können. Struts bringt einige vorgefertigte Validatoren mit (z. B. für die Prüfung, ob ein Feld ausgefüllt ist oder eine valide Zahl enthält). Stellt ein Validator einen Fehler fest, wird automatisch auf die Ausgangsseite zurückgeleitet und der Fehler angezeigt. Es ist aber auch möglich den Fehler via Javascript clientseitig prüfen zu lassen und den Fehler noch vor dem Absenden des Formulars in einem Fenster anzuzeigen.
[Bearbeiten] Die Datenhaltung
Die Form-Bean ist eine normale Java Bean, die alle benötigten Daten für die JSP und die Action enthält. Sie ist die Schnittstelle zwischen diesen beiden Komponenten und wird über die struts-config mit einem Formular in der JSP verknüpft. Wenn das Formular abgeschickt wird, wird die Bean durch das ActionServlet (noch bevor die Action ausgeführt wird) über die setter-Methoden mit den entsprechenden Eingabewerten gefüttert.
Die FormBean enthält außerdem eine Validierungs-Methode, welche (wenn in der Konfiguration aktiviert) die Daten der Form-Bean prüft, bevor sie zur Action geschickt werden. Außerdem enthält sie eine reset-Methode um den Inhalt zurückzusetzen, damit sie wiederverwendet werden kann (was den Aufwand für die Speicherverwaltung reduziert – siehe: Slab allocator).
Da diese Art der Datenhaltung oft zu starr ist (siehe Kritik), wurde von den Struts-Entwicklern die Möglichkeit geschaffen, die Beans in der struts-config.xml zu deklarieren, wodurch die starre und aufwendige Programmierung der Beans entfällt. Zum Zugriff wird dann die ActionForm zu einer DynaBean des Apache Commons BeanUtils Projekt gecastet und die Daten werden dann über Schlüssel erfragt. Bei der Verwendung dynamischer Beans kann außerdem zur Validierung das Commons Validation Framework eingesetzt werden.
[Bearbeiten] Die Action
Die Action ist diejenige Komponente, die mit dem Backend kommuniziert, von ihr Daten holt und sie auch wieder dahin schreibt. Sie enthält meist weitere Prüf- und Auswertungsmechanismen. Sie speichert die Daten in der Form-Bean ab und liest sie, nachdem die Seite abgeschickt wurde, wieder aus. Daher gilt es als Unsitte, die Daten hier direkt in den Request zu speichern; dazu ist schließlich die Form-Bean da.
Die Action ist ebenfalls für die Navigation durch die Webseite verantwortlich, da sie nach getaner Arbeit ein ActionForward zurückgeben muss. Dieser Forward hat einen bestimmten Namen, im Falle unseres Beispiels kann dieser "failure" oder "success" lauten. Je nachdem, welchen Forward die Action zurückgibt, entscheidet das Struts-Framework anhand der struts-config, zu welcher Seite weitergeleitet werden soll.
[Bearbeiten] Kritik
Neben den Vorteilen von Struts existieren auch folgende Nachteile.
- Die Programmierenden müssen selbst darauf achten, dass ihre Actions sicher bezüglich Nebenläufigkeit sind. Dies ist deshalb riskant, weil eine Action gleichzeitig durch mehrere parallele Threads des Web-Servers aufgerufen werden kann.
- Actions sind nur als abstrakte Klassen definiert, nicht als Schnittstellen. Dies ist von Nachteil, weil beim Programmieren Implementierungsdetails beachtet werden müssen, was unübersichtlich und unflexibel ist. (Siehe hierzu auch das Entwurfsmuster Kommando.)
- ActionForms bilden häufig große Teile der fachlichen Klassenstruktur nach. Dies erhöht zum einen den Aufwand beim Erstellen der Anwendung und zum anderen die Wartungskosten. Dies lässt sich mit der Verwendung dynamischer Beans lindern.
- Actions sind keine POJOs, das heißt, sie sind verschmutzt mit technischen Details, mit der Signatur der Struts-Actions-Klasse (gilt nur für das traditionelle Struts/Action1).
- Struts ist ein reines Web-Framework und sollte nicht genutzt werden um beispielsweise Java-Swing-Applikationen zu erstellen, auch wenn es für diesen Zweck entsprechende Beispiele gibt.
- Struts sieht sich immer mehr der Konkurrenz von leichtgewichtigen Frameworks wie Spring ausgesetzt. Wird mit dem neuen Action-2-Framework durch dessen Modularität teilweise verbessert.
- Struts nutzt JSPs und erbt somit deren Nachteile. Manche Entwickler bevorzugen die Nutzung eines Frameworks wie Tapestry, welches zur Darstellung nicht JSP nutzt, sondern eine Template Engine.
[Bearbeiten] Lizenz
Struts ist unter der Apache-Lizenz veröffentlicht.
[Bearbeiten] Siehe auch
- Webanwendung
- JavaServer Faces
- JSTL
- MVC
- Ruby on Rails, ein anderes MVC Framework für Webanwendungen
- Web Dynpro, MVC-basierte, serverseitige Web-GUI-Technologie von SAP
[Bearbeiten] Literatur
- Matthias Weßendorf: Struts – Websites mit Struts 1.2 & 1.3 und Ajax effizient entwickeln.( 2. Auflage) W3L, Herdecke 2006, ISBN 3-937137-26-2
- Michael Albrecht, Manfred Wolff: Struts ge-packt. MITP, Bonn 2004, ISBN 3-8266-1431-3
