Seite 4: Nichts für große Anwendungen, Fazit

Inhaltsverzeichnis

Nichts für große Anwendungen

Sofern eine große, komplexe Anwendung jenseits von CRUD erforderlich ist, kann Spring Roo bis dato noch nicht viel helfen. Zwar lässt sich theoretisch das Grundgerüst für die Anwendung erzeugen und dann erweitern, doch entsteht hier der Nachteil, dass der Entwickler an die Eigenheiten von Spring Roo gebunden ist, unter anderem wird für die Persistierung das Active Record Pattern verwendet.

Die GWT-Unterstützung sei hier als Negativ-Beispiel genannt, da sie im Moment zahlreiche Java-Klassen und XML-Dateien pro Entität in mehreren Packages generiert.

Oftmals sind Anforderungen oder Richtlinien im gesamten Unternehmen beziehungsweise Bereich gültig, an die die Anwendung angepasst werden müsste. Spring Roo lässt sich zwar mit geringem Aufwand vollständig aus einem Projekt entfernen, dennoch bleibt als Ergebnis eine Anwendung mit der von Spring Roo generierten Struktur und den eingesetzten Frameworks, wie Spring oder Log4J.

Neben dem "Vorschreiben" bestimmter Frameworks und Konzepte tauchen in diesem Zusammenhang noch zwei weitere Probleme auf, die zum jetzigen Zeitpunkt gegen den produktiven Einsatz von Spring Roo in komplexeren Projekten sprechen:

• fehlender Support für mehrere Maven-Module. Allerdings sind in der Praxis komplexere Projekte fast immer auf mehrere Module aufgeteilt.
• fehlendes Undo-Kommando: Dies bedeutet, dass nach einem Tippfehler in der Roo-Shell oder der versehentlichen Ausführung eines Kommandos das ganze Projekt zu durchsuchen ist, da bei der Code-Generierung oft nicht klar ist, wo alles etwas verändert wurde. In Foren vorgeschlagene Workarounds wie die log.roo-Datei, das Backup-Kommando der Roo-Shell oder ein lokaler Git-Commit nach Änderungen sind zwar möglich, verhindern aber effizientes Arbeiten.

Man arbeitet bei Spring Roo jedoch schon an möglichen Lösungen für diese beiden Probleme.

Alternativ kann man Spring Roo nur für Teile eines Projekts verwenden, beispielsweise für die Erzeugung der Entitäten. Oder man verwendet zwei getrennte Oberflächen für eine Webanwendung: Eine komplexe Oberfläche für die eigentlichen Anwender und eine einfache CRUD-GUI für Administratoren zur Verwaltung der Nutzer, der Rechte oder Ähnlichem. Hier ist eine saubere Trennung möglich, um die einfache CRUD-GUI schnell und ohne optische Finessen mit Spring Roo zu erzeugen.

Für und Wider Prototyping

Es wird oft damit geworben, dass ein Entwickler mit Spring Roo "nur" den Prototypen zu erstellen braucht und Roo anschließend einfach entfernen kann. Spring Roo ist nun in erster Linie für CRUD-Clients geeignet. Sofern es nur für die Erstellung eines Prototyps genutzt werden soll, müssten man sich folgende Fragen beantworten:

• Benötige ich nur eine CRUD-Anwendung? Wieso benötige ich dann einen Prototyp? Die Anwendung kann schließlich nur Daten schreiben, lesen, aktualisieren und löschen.
• Benötige ich eine komplexe Anwendung, also nicht nur CRUD? Wie kann mir Spring Roo dann eigentlich dabei helfen?
• Möchte ich eine Spring-Anwendung erstellen? Ich kann Spring Roo, das heißt die AspectJ-Dateien und die Roo-Annotationen, zwar schnell vollständig entfernen, aber habe danach trotzdem noch eine Spring-Anwendung.
• Kann ich die von Spring Roo generierten Klassen weiterhin sinnvoll benutzen, wenn Spring Roo entfernt ist? Sind die verwendeten Strukturen und Konventionen mit den Richtlinien des Unternehmens vereinbar? Ansonsten kann der Aufwand für das Refactoring größer sein als die vorherige Zeitersparnis bei der initialen Erstellung des Projekts mithilfe von Spring Roo.

Fazit

Spring Roo ist gut geeignet für eine effiziente Realisierung von CRUD-Anwendungen. Auch das Lernen von neuer Techniken und Aufsetzen von Spring-Projekten sind sinnvolle Einsatzgebiete. Für den Einsatz in komplexeren Projekten ist Spring Roo hingegen noch nicht empfehlenswert. Dabei gilt es zu beachten, dass es noch ein junges Produkt ist, das aber schon eine beachtliche Community hinter sich weiß, sowie mit SpringSource einen Hersteller, der die zügige Weiterentwicklung vorantreibt und ein breites Spektrum an Spring-Projekten zur Integration anbietet. Es ist zudem nur eine Frage der Zeit, bis sich die Qualität der bisherigen Add-ons von Drittherstellern stabilisiert.

Jeder Java-Entwickler sollte Spring Roo zumindest kennen und wissen, wann er es sinnvoll einsetzen kann. Wie auch bei anderen Open-Source-Projekten empfiehlt es sich zudem, darüber nachzudenken, sich in der Community zu engagieren. Dafür muss nicht unbedingt selbst Code committed werden – bereits die Teilnahme an Diskussionsforen oder das "Voten" auf gewünschte neue Funktionen im Spring Roo Issue Tracker sind wertvolle Beiträge.

Kai Wähner
ist IT-Consultant bei der MaibornWolff et al GmbH. Seine Schwerpunkte liegen in den Bereichen Java EE, EAI und SOA. Außerdem ist er Autor von Fachartikeln, hält Vorträge und Workshops auf IT-Konferenzen und berichtet in seinem Blog über Erfahrungen mit neuen Technologien. (Twitter: @KaiWaehner). ()