Die Persistenz-Layer nutzt transparente Persistence und der Name des Layers ist Repository. Es gibt eigene Finder. Validierung und Logik ist im Domain Model. Viel von dem Code wird generiert. Generierung hat natürlich einige Probleme wie das erneute Generieren, die Qualität des generierten Codes, Versionskontrolle usw.
ROO kommt aus konkreten Projekt-Szenarien. Es legt die Priorität auf die Implemeniterung des Domänen-Modells. Und das ganze soll möglichst gehen.
Eine ROO-Anwendung ist mit einem Maven Archetype leicht zu erstellen. Danach kann man Properties für die Datenbank editieren. Als nächstes erzeugt man dann die Domänen-Objekte. Diese enthalten zum Beispiel die Logik für gültige Werte in Form von asserts. Daraus wird das Hibernate-Mapping erzeugt. Und auch passende Oberklassen für die Integrations-Tests. Dadurch werden dann auch die Datenbank-Tabellen erzeugt. Der Generator überschreibt die generierten Files nicht.
Die Persistenz verlässt sich auf transparente Persistenz, d.h. man kann es nicht mit JDBC verwenden, was explizite Save-Operationen nutzt. Finder sind in eigenen Klassen, die man dadurch leicht injizieren kann und austauschen kann. Dazu bietet es auch ein eigenes Mocking-Framework an. Und es werden auch Oberklassen für die Integrations-Tests erzeugt.
Es gibt eine Fassade, um die Logik in den Domänen-Objekten auch als Serivces zu exportieren. Ben wies dann darauf hin, dass Domänen-Objekte keine DTOs sind. Für die Konvertierung wird Dozer genutzt. Ein Domänen-Objekt ist nicht unbedingt ein DTO, so dass mehrere Domänen-Objekte in einer Fassade zusammengefasst werden. Dadurch hat man keine Explosion von Typen.
ROO-Anwendungen sind auch automatisch JMX-fähig, so werden die Hibernate-Statistics exportiert und auch eigene Informationen zum Beispiel über die DAOs.
Woolworth in Australien verwendet ROO schon. Dort gab es dann auch die Anforderung, komplexere Datenbank-Schemata zu unterstützen. Außerdem musste Dozer angepasst werden. Ein externes Review der Projekte war positiv und die Projekte war on Time und in Budget. Außerdem sind ROO-Applikationen konsistent.
Ben hat den Vortrag auch schon auf der Spring Experience gegeben, hier kann man ein Blog-Eintrag darüber lesen.
Labels: Ben Alex, ROO, SpringOne
¶ 12:09
