Vaadin ist ein Framework, das die Erstellung von Rich-Internet-Applications mit Java ermöglicht. Damit entsteht eine Brücke von existierenden Softwarearchitekturen und Skills zur nächsten Generation von Unternehmensanwendungen im Web. Das Framework an sich reduziert die Hürde für die ersten Schritte bereits – Projekte steigern ihre Produktivität und Erfolgschance durch die Anwendung einiger Best Practices, die dieser Artikel vorstellt.

Vaadin ist eine moderne und gleichzeitig relativ reife Technologie zur Umsetzung von Web-Anwendungen in Java. Das Framework ist seit 2007 Open-Source und hat sich eine rege Community erarbeitet. Vaadin verbindet dabei Styling und Experience von Web 2.0 mit der Stabilität und Effizienz der verbreiteten Java-Plattform, einschließlich Typsicherheit und Debugging.

Für Geschäftsanwendungen (Intranet, Extranet und darüber hinaus) ergibt sich damit eine neue Chance. Mit den in vielen Teams bereits aufgebauten Java-Kenntnissen lässt sich eine komplette Web-Anwendung entwickeln. Dabei wird auf dem Anwendungsserver ein Komponentenbaum erzeugt und (sehr gut optimiert) auf den Browser gespiegelt (Abb.1). Umgekehrt werden Ereignisse vom Client zurück auf den Server übertragen und dort behandelt. Der Custom-Code kann und wird sich dabei im ersten Schritt auf Javacode beschränken der in einer Java-IDE entwickelt wird und auf dem Server läuft.

Teams können so in einer gewohnten und effizienten Umgebung arbeiten – Stichwort Developer Experience – und erreichen dabei eine hohe Produktivität. Gleichzeitig bringt das Framework einen substanziellen Default-Style mit, sodass die Anwendung mit einem guten Eindruck startet und eine gute User Experience bietet, selbst wenn dazu mehr gehört. Vaadin stellt eine umfangreiche Beispielsammlung vom einfachen Button bis zur Registrierungsform bereit. Darüber hinaus existieren Praxisanwendungen aus diversen Industrien.

Vaadin erreicht dabei eine sehr gute Performance trotz des nötigen Abgleichs zwischen Client und Server und dafür nötigen Session-Inhalten.

Obwohl der Einstieg in Vaadin dank einer guten Dokumentation und der Community um das Framework sehr leicht fällt, zeigt unsere Erfahrung, dass die Produktivität und insgesamt der Erfolg von Vaadin-Projekten durch die Anwendung einiger weiterer Best Practices substanziell beeinflusst wird. Dieser Artikel stellt drei zentrale Praktiken kurz und konkret vor.

Strukturierung der UI-Logik (Model-View-Presenter)

Die Implementierung von Benutzeroberflächen mit Vaadin erfolgt im Java-Code. Zwar lässt sich das Design durch den Einsatz von CSS/SCSS verändern, die Struktur der UI wird in jedem Fall im Java-Code bestimmt. Bei komplexeren Anwendungen wächst dabei sehr schnell die Code-Menge, die den Aufbau und das Verhalten der UI-Elemente bestimmt. Damit besteht die Gefahr, dass die Lesbarkeit leidet und die zunehmende Komplexität Erweiterungen behindert. Fehler schleichen sich ein und die Entwicklungsgeschwindigkeit bricht ein. Eine stringente, strukturierte und skalierbare Code-Struktur kann hier Abhilfe schaffen. Model-View-Presenter (MVP) ist ein Weg, diese zu erreichen (Abb.2).

Das Model-View-Presenter-Pattern ist ein Architektur-Pattern, das die Bereiche Darstellung, UI-Logik, Geschäftsdaten und -logik auf die Rollen View, Presenter und Model verteilt und durch den Einsatz von Interfaces entkoppelt. Der renommierte Softwarearchitekt Martin Fowler beschreibt zwei Varianten des Entwurfsmusters: Supervising Controller und Passive View. Dieser Artikel behandelt letztere Variante. Üblicherweise implementieren Services und Datenobjekte dabei die Rolle des Models und stellen Methoden zum Datenzugriff zur Verfügung. In der View befindet sich der Code, der die UI tatsächlich darstellt, jedoch keine weitere Logik enthält. Alle Events (z.B. Button-Clicks) werden an den Presenter weitergeleitet, der als View-Observer agiert. Dieser entscheidet dann was zu tun ist und delegiert Aufgaben ggf. an die Serviceschicht weiter. Daneben befüllt der Presenter den View mit den nötigen Daten.

Bei komplexen UIs gibt es in der Regel einen Haupt-View, der Navigations-Panel und Content-Bereich enthält. In dem Content-Bereich kann es weitere Verschachtelungen geben. Mit dem MVP-Pattern lassen sich solche hierarchischen Szenarien gut lösen, indem pro Ansicht ein View-Presenter-Paar geschaffen wird. Die Kommunikation zwischen den Ansichten läuft ausschließlich zwischen den Presentern. Hier kann mit Observer-Beziehungen oder mit Event-Bussen gearbeitet werden.

Weiterhin ist es äußerst ratsam, den View, den Presenter und das Model in Interface und Implementierung aufzutrennen. Die View-Implementierung kapselt dabei das Vaadin-Framework. Der Presenter greift nur auf den View als Interface zu und ist Vaadin-frei. Dadurch kann der Presenter gut mit Unit-Tests  bgedeckt
werden. Die View-Implementierung wird dafür durch einen Mock ausgetauscht.

Die Verwendung von MVP bringt mehrere Vorteile mit sich:

• Die Funktionalität jeder Ansicht ist gut gekapselt, dadurch
  wiederverwertbar und hat eine gute Lesbarkeit.
• Presenter und die darin enthaltene Logik sind Unit-testbar
• Auch in komplexen und verschachtelten UIs existiert eine
  beherrschbare Struktur.

Außerdem ist die Kapselung von Vaadin in der View-Implementierung nützlich bei Versionssprüngen in Vaadin (z.B. von 6 nach 7 oder von 7 auf 8). Änderungen bei der Portierung bleiben so lokal und der Umbau wird komplexitäts- und risikoarm.

Wachsen Richtung JavaScript

Einer der Hauptvorteile von Vaadin besteht darin, dass Standardanforderungen an die UI in kurzer Zeit umgesetzt werden können. Mithin bestehen allerdings UI-Anforderungen, die speziell sind und für die es keine Standardlösung in Vaadin gibt. In den meisten Fällen kann dabei auf Add-ons im Vaadin-Directory zurückgegriffen werden oder es ist eine serverseitige Implementierung möglich. Gilt es dennoch, eine clientseitige Anforderung umzusetzen, so lässt sich dies bei Vaadin mit Hilfe von GWT-Komponenten tun oder direkt mit JavaScript. Es ist in vielen Fällen ratsam, JavaScript zu nutzen, da die Entwicklung mit GWT aufgrund der langen Kompilierungszeiten von Java nach JavaScript etwas sperrig ist und auch die Debug-Möglichkeiten mit dem sogenannten Super-Dev-Mode unhandlich sind. Diese Beschränkungen entfallen beim Einsatz von JavaScript mittels beispielsweise JavaScript-Extensions, da GWT außen vor bleibt. Umfangreichere Vorhaben lassen sich zunächst unabhängig von Vaadin entwickeln und anschließend integrieren. So existiert für die Umsetzung mit AngularJS ein Add-on Vaangular, welches die nötige Brücke schafft. Daneben ist das Debuggen von nativem JavaScript im Browser sehr einfach und gut unterstützt. Neben eigener JavaScript-Entwicklung lassen sich JavaScript-Libraries von Drittanbietern schnell auf die gleiche Weise Vaadin-ready machen.

Optimierung im Widgetset-Build

Das Widgetset oder auch Clientside-Engine in Vaadin ist eine generierte JavaScript Bibliothek, die aus GWT-Code (Java) kompiliert wird. Sie enthält die clientseitigen Komponenten und die Vaadin-Engine, die im Browser läuft. Das Widgetset wird bei einer Vaadin-Anwendung beim Start vom Server im Browser geladen. Wird im Projekt nur der Vaadin-Core benutzt ohne zusätzliche Add-ons mit GWT-Code, kann der Bau des Widgetsets entfallen und das fertig kompilierte Default-Widgetset als Maven Dependency verwendet werden. Leider ist es bei den meisten Projekten nicht so einfach. Da schnell Addons mit GWT-Code ins Spiel kommen, muss das eigene Widgetset gebaut werden. Hier bietet Vaadin zwar mittlerweile an, diesen Bau auf die Vaadin-Cloud
auszulagern. Dies ist allerdings bei restriktiveren Unternehmensnetzwerken nicht immer möglich oder gewollt. Es bleibt, den Bau selbst auszuführen.

Das Erstellen des Widgetsets dauert relativ lange, im Vergleich zum serverseitigen Java-Code. Wird bei jedem Build auch das Widgetset erstellt, hat es signifikante Auswirkungen auf die Laufzeit des Builds. In den meisten Fällen ist jedoch kein Neubau des Widgetsets nötig, da ausschließlich serverseitiger
Code modifiziert wird.
Unsere Best-Practice hierzu ist die Erstellung eines eigenen Widgetset-Projekts für das jeweilige Projekt. Das eigentliche Projekt referenziert dann nur das fertige Artefakt des kompilierten Widgetsets aus dem Firmen-Repository. Dadurch gibt es keinen Widgetset-Bau, der nicht nötig ist. Muss doch das
Widgetset angepasst werden, gilt es die neue Widgetset-Version im Hauptprojekt zu referenzieren.

Fazit

Vaadin ermöglicht einen schnellen Einstieg in die Entwicklung von Web-Anwendungen für Java-zentrierte Teams. Während das Framework als solches sowie gute Dokumentation und Community vieles schon erleichtern, steckt ein zentraler Hebel für Produktivität und Erfolg im Projekt in der Anwendung von Best
Practices, die über den Lieferumfang hinausgehen. Allen voran ist das die Strukturierung der UI-Logik mittels MVP. Auf Basis einer solchen Struktur wird ein Hineinwachsen in die Web-Entwicklung möglich – einschließlich fortgeschrittener Entwicklung auf dem Client.

[accordion]
[/accordion]

Diesen Artikel finden Sie auch in der Erstausgabe der JAVAPRO. Einfach hier kostenlos bestellen.