Grails 2.0

Konsequent persistent

In einer Umfrage [1] waren für die Entwickler von Grails-Applikationen
die neuen Persistenz-Features das wichtigste.

Obwohl der Zugriff auf relationale Datenbanken weiterhin der Fokus
von Grails bleibt, gibt es nun neue Integrationsmöglichkeiten für
NoSQL-Alternativen wie MongoDB, Redis, Riak, etc.
Dabei ist besonders angenehm, dass man auch auf die NoSQL-Datenquellen
mit den üblichen GORM-Mitteln wie dynamische Finder-Methoden zugreifen
kann. In vielen Fällen kann man also bei der Umstellung auf eine
NoSQL-Quelle den Applikationscode unangetastet lassen.

Auch auf der klassischen relationalen Seite gibt es interessante
Neuerungen. Mein Favorit: eine hasMany-Referenz mit dem Datentyp
Collection deklarieren und eine Hibernate Bag geschenkt bekommen!
Das kann auf die Performance erhebliche Auswirkungen haben, weil
die alternativen Datentypen Set und List die Eindeutigkeit, resp. Reihenfolge sicherstellen müssen und deshalb allzu häufig den
Cache invalidieren.

Es gibt noch sehr viel mehr Neuigkeiten, deren Details man in der
Dokumentation unter „What’s new“ nachlesen kann. Hier nur ein
Überblick:

  • Bereitstellen von wiederverwendbaren und miteinander verknüpfbaren Criteria Queries außerhalb einer Session (Detached Criteria)
  • Typsichere, Compile-Zeit-geprüfte Queries als arithmetische Ausdrücke (Where Queries)
  • findOrCreate– und findOrSave -Methoden
  • Abstrakte Domänen-Oberklassen (bisher nur per Interfaces)

Außerdem stehen jetzt standardmäßig Fähigkeiten bereit, die bisher nur über Plug-ins vefügbar waren:

  • Multiple Data Sources
  • Schemaevolution (Database Migrations)
  • Database Reverse Engineering

Sehr schön ist auch, dass man im Development-Modus jetzt einfach die /myapp/dbconsole URL aufrufen kann, um im Browser direkt auf die Datenbank zu schauen. Das geht selbst mit der In-Memory-Datenbank, die jetzt von HSQLDB auf H2 umgestellt wurde.

Alles unter Kontrolle

Für die Controller wurde eine neue Möglichkeit geschaffen, Actions nicht mehr
nur als Closures zu definieren, sondern alternativ als Methoden mit den benutzten
Http-Request-Parametern als formalen, typisierten, automatisch gebundenen Parametern. Das ist nicht nur schneller, sondern erlaubt auch eine bessere
IDE-Unterstützung und besser lesbare Stacktraces im Fehlerfall.

Dazu kommt noch eine Menge von Verbesserungen für das Rendern von Links oder
ganzen Seiten (auch außerhalb eines HttpRequests), leichteres Binden von
Datums-Parametern, flexible URL-Formate (kleinGross oder mit-bindestrich),
leichtes Einbinden für die asynchrone Abarbeitung gemäß dem Servlet-3.0-Standard,
Ausschlusskriterien für Filter und das automatische Anlegen von
Unit-Tests für Controller.

Damit kommen wir zum Testen

Nicht nur wurden die Test-Ausgaben auf Konsole und im HTML-Report erheblich
verschönert, auch die Tests selbst sind so mächtig geworden, dass man mehr und mehr
die langsameren Integrations-Tests durch die schnellen Unit-Tests ersetzen kann.
Das gilt für die Domänenklassen mit ihren Constraints und GORM-Methoden wie in
Listing 3 und für die Verzweigungs- und Datenbereitstellungslogik in den
Controllern.

Listing 3
package grails2

import grails.test.mixin.TestFor

@TestFor(Person)
class PersonTests {

    void testWhere() {
        mockDomain(Person, [new Person(firstName: "Dierk", lastName: "König", birthday: new Date())])
        def query = Person.where { firstName == "Dierk" }
        def result = query.find()
        assert result.lastName == "König"
    }
}

Statt Vererbung setzt Grails 2.0 für die Tests auf Groovy Mixins mit der
@TestFor Annotation.

Dies und das

Grails 2.0 verwendet Groovy 1.8, Hibernate 3.6 und Spring 3.1, das jetzt
die sogenannten Profiles unterstützt. Sie sind ähnlich zu dem, was in Grails
die Environments sind und von Grails mit berücksichtigt werden.

Plug-ins wurden bisher nur als Quellcode ausgeliefert und mit dem Verwender zusammen
kompiliert. Jetzt kann man sie auch binär ausliefern.

Außerdem kann sich jeder Entwickler bereit erklären, am Plug-in-Tracking
teilzunehmen. Das erlaubt dem Grails-Team eine bessere Einschätzung, wie populär die
mehr als 700 Plug-ins jeweils sind, und wo sich weitere Investitionen am meisten lohnen.

Die Resolutionslogik zu abhängigen Bibliotheken wurde optimiert, um mit weniger
Netzzugriffen auszukommen.

Zu guter Letzt hat auch die integrierte Dokumentationsmaschine grails-doc
einen Facelift erfahren, sowohl im Aussehen, wie auch bei den internen
Strukturierungsmöglichkeiten.

Umstellungsaufwand

Bei dieser Menge an neuen Features möchte man natürlich so schnell wie möglich
auf die 2.0 Version upgraden – und fürchtet dabei den Aufwand.

Zuerst sollte man sich die Sektion 2.3 „Upgrading from previous versions of Grails“
der Dokumentation anschauen, die einen ersten Eindruck vermittelt.

Wer sich bisher ausschließlich an das offizielle API gehalten hat und dem Rat seines
Grails-Consultants folgte, was gute Tests, sinnvolle Versionskontrolle und das Vermeiden von Duplikation angeht, der kann mit einem sicheren und schmerzarmen Upgrade rechnen.
Wenn man auf die neuen Features wie z.B. „Where Queries“ umstellen möchte, ergibt sich
natürlich ein Mehraufwand.

Für mich waren die meisten Grails-Applikationen leicht und schnell umzustellen, andere
haben unerwartet mehr Aufwand erzeugt. Bei letzteren war es aber ausnahmslos meine
eigene Schuld, und am Ende war ich froh über die neue, einfache und saubere Lösung.

Viel Spaß mit der neuen Grails-Version im Neuen Jahr!

Dierk König ist Fellow bei der Canoo Engineering AG, Basel. Er betreibt das Open-Source-Projekt Canoo WebTest und ist Committer in den Projekten Groovy, Grails und GPars. Er publiziert und spricht auf internationalen Konferenzen zu Themen moderner Softwareentwicklung. Er ist Autor des Buchs „Groovy in Action“. Twitter: @mittie
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.