[Grails eXchange] Session GORM-ORM with Hibernate Demystified (Graeme Rocher)

Graeme, Project Lead von Grails, zeigt den Object-Relational Mapper in Grails (GORM, wobei G für Groovy steht). Dieses Tool ist auch separat von Grails einsetzbar. In Grails ist es einer der Hauptstützfeiler der Architektur.

Hibernate steckt unter der Haube von GORM. Anders als bei Ruby on Rails (RoR) nutzt Grails kein ActiveRecord-Pattern, um die Persistenzgeschichte zu erledigen. Grails leitet via GORM die Informationen direkt aus den Domainklassen ab. Da stecken gut durchdachte Defaulteinstellungen dahinter. Tatsächlich gibt es, sofern man nichts tweaken muss, keinen Bedarf an Mapping-Files, wie man sie in Hibernate normalerweise nutzt.

Graeme führt gerade die Vorteile von Hibernate aus und begründet damit den Einsatz in Grails. Ich spare mir das mal hier: Hibernat ist gut und daher in Grails enthalten.

Interessant ist, wie GORM das Mapping aus den Domainklassen zieht. Groovy ist dynamisch und statisch typisierbar. In Domainklassen nutzt man das statische Typisieren, um Informationen zu bekommen für den Typ der Tabellenspalte in der Datenbank.

Mit statischen Maps wie hasMany oder belongsTo steuert man die Abbildung der Assoziationen zwischen Domainklassen, zumindest was die Aggregationen angeht. Es können Sets und SortedSets benutzt werden, ebenso wie Maps und Lists.

Früher konnte man Legacy Datenbanken anbinden, indem man in Grails Mapping-Dateien einbindet, um die Domainklassen mit den Alttabellen zu verbinden. Jetzt gibt es die neue Mapping-DSL, mit der man das in der Domainklasse selbst machen kann, und zwar eben genau so viel, wie man braucht. Dort, wo man nichts angibt, fällt man zurück auf das Default-GORM-Verhalten.

GROM bietet dynamisch Methoden an den Domainklassen zur Verfügung, etwa save(). Hat man eine Aggregation etwa zwischen Author und Book, dann kann man sagen

autor.addToBooks(book)
autor.removeFromBooks(book)

Constraints, wie man sie früher entkoppelt vom Domänenmodell in der Datenbank pflegen musste, werden nun abgeleitet aus einer Deklaration im Domänenmodell. Ist das DRY oder was?! In jeder Domänenklasse kann man, naürlich via einer ausgeklügelten DSL, Constraints definieren.

Graeme zeigt Teile der oben beschriebenen Features nun live. Interessant dabei: Die Constraints beeinflussen auch die Validierung von an der Oberfläche eingegebenen Werten. Die Fehlermeldungen werden dabei aus einer message.property (normales I18n-Verhalten aus Java) angezeigt, die man zur Laufzeit ändern kann. Die zur Verfügung stehenden Validierungsmöglichkeiten sind vielfältig. Die Validierungen werden automatisch beim Speichern eines Domänenobjektes validiert. Kann man alles sehr schön schnell live erleben, wenn man sich mal eine kleine Beispielapplikation scaffolded.

Wieder zurück in den Folien zeigt Graeme die dynamichen Finder-Methoden. Hat ein Book ein en Title, dann kann man schreiben

Book.findByTitle("Harry Potter and the Goblet of Fire")

Nett: Graeme bemüht die GroovyConsole, die in Grails eingebettet ist. Damit kann man auf so ziemlich Alles, insbesondere hier auf die Domainklassen, zugreifen, und mal eben schnell etwas ausprobieren. Wird aufgerufen über grails console Wie bei Hibernate auch, kann man etwas suchen, wenn man ein Beispielobjekt zur Verfügung stellt. Und schließlich kann man auch via Hibernate-Kriterien suchen - mit dem HibernateCriteriaBuilder, der eine gute DSL dafür zur Verfügung stellt.

Alle Aktionen sind transaktional, wenn man möchte. Das wird durch Spring zur Verfügung gestellt. Das transaktionale Verhalten kann wiederum via Grails beeinflusst werden. Optimistisches Locking ist Default, kann aber via lock()-Methode umgestellt werden aufs Pessimistische Locking.

(Fast) Nichts Neues für mich; guter Vortrag. Empfehlenswert.