Tag 1: 13:30 - 16:30: Spring Roo

Das wohl ewige Mantra in der IT lautet: Software-Entwicklung muss einfacher werden und sich ausschließlich auf das Business konzentrieren können.

Ein schöner Gedanke, und manche Frameworks/Konzepte sind ihn in ebensolcher Schönheit gestorben.

Spring Roo versucht anders zu sein. Aber der Reihe nach.

Spring Roo ist ein Rapid Application Development Tool (RAD) und liegt aktuell in der Version 1.1.0 vor. Es versucht den für eine Web-Anwendung zu schreibenden Code sowie die zugehörige Konfiguration auf ein Minimum zu reduzieren, ohne dabei an Funktionalität einzubüßen. Das kennt man im Grunde von Rails oder Grails.

Das Fundament von Roo besteht im wesentlichen aus

• dem Spring-Ökosystem (Framework, Security, Annotations, tc Server, etc.)
• Hibernate plus weiterer OR-Mapper und entsprechend unterstützter Datenbanken
• einer Roo Shell (wichtig!)
• AspectJ (noch wichtiger!)
• Roo Add-ons und Annotations
• Integration in Spring STS

Die Roo Shell bietet ein ausgefeiltes Set an Kommandos zur Erzeugung und Verwaltung von Roo-Projekten (Maven-basiert) und den darin aufzubauenden Klassen an. Autovervollständigung unterstützt den Programmierer bei der Nutzung (sehr gut gelöst!).

Wenn man aktuell Spring-basierte Web-Anwendungen bauen will, dann sind diverse Dinge zu programmieren, die man eigentlich geschenkt bekommen möchte, da sie sich eh immer wieder wiederholen, z. B.:

• get-/set-Methoden für Properties
• DAOs mit Standard-CRUD- und Finder-Operationen
• GUIs mit Standard CRUD-Benutzerelementen (z. B. Listen mit Paginierung)

Roo macht all dies überflüssig. Der Schlüssel hierzu liegt in dem Einsatz von AspectJ als "Methoden-Generator": Über die Roo Shell erzeugte Business-Objekte und deren Felder werden um automatisch generierte AspectJ-Dateien angereichert, welche z. B. Getter und Setter sowie toString() u. ä. bereitstellen. Ein zusätzliches Projekt (Hades) erlaubt es als Plugin in Roo die Generierung von Findern.

Durch die Verwendung von Roo-Kommandos bleibt einem auch der wesentliche Teil der Spring-Konfiguration erspart.

Zusätzliche Add-ons (die man auch selber schreiben kann) erleichtern massiv den Umgang mit Technologien/Bibliotheken, wie z. B.:

• REST
• JSON
• AJAX (Dojo ist Default)
• Spring Web Flow
• Spring Security
• i18n

Wichtig ist bei alledem, dass Roo lediglich zur Entwicklungszeit "greift": Es sind keinerlei Laufzeitkomponenten notwendig, die über die "klassischen" Spring-Bibliotheken hinaus gehen. AspectJ und die Compile-time-Annotation @Roo machen's möglich.

Sehr elegant: Änderungen im Code werden automatisch in die laufgende Anwendung übernommen. Darüber hinaus werden DB-Änderungen nach Aufruf eines Roo-Shell-Kommandos EBENFALLS übernommen. Dies betrifft sämtliche Schichten von der Domainklasse bis hin zur GUI!

Durch die FinCon-Brille betrachtet ist Spring Roo hochinteressant:

• Die Tools scheinen ausgereift
• Der Tool Stack unter Roo ist uns (fast) komplett bekannt
• In einzelnen Bereichen reduziert sich der Programmieraufwand erheblich
• Sinnvolle gefüllte Testklassen werden automatisch mitgeneriert
• Der Build-Redeploy-Roundtrip sollte sich erheblich verkürzen

Ein Einsatz sollte definitiv in Betracht gezogen werden.

Aus meiner Sicht gibt es aber folgendes zu bedenken: Als Client-Technologie kommen out-of-the-box JSP (!) plus Roo-eigene Taglibs zum Einsatz. Einzige genannte Alternative: GWT. Dies entspricht NICHT unserem Tool Stack, welcher sich bei aktuellen (Neu-)Entwicklungen auf JSF konzentriert.

Diese "Kröte" könnte man aber schlucken:

1. JSPs sind bei vielen unserer Entwickler bekannt.
2. Im Fokus steht das Entwickeln von JEE-konformen Web-Anwendungen. Wenn Schnelligkeit in der Entwicklung eine deutlich höhere Priorität gegenüber den verwendeten Bibliotheken hat, dann ist besonders bei neuen Anwendungen die Wahl der (UI-)Waffe egal.