Artikel

 
Oktober 2009 | Artikel

Einstieg in Spring Roo RC2 Fortsetzung, Teil 2

Teil 1   Teil 2   Teil 3   Teil 4   

Domänenklasse

Als nächstes benötigen wir eine Domänenklasse:

  1. roo> entity --name ~.HolidayRequest

Roo hat nun eine (fast) leere Klasse mit dem Namen HolidayRequest erstellt. Die Tilde wird durch das Top Level Package ersetzt, das beim Anlegen des Projekts angegeben wurde. In unserem Beispiel ist dies hra. Es wurden auch einige „.aj“ -Dateien erstellt. Für was sind diese Dateien? Die Klasse HolidayRequest soll eine Entität sein, und benötigt daher auch eine ID für den Primärschlüssel, eine Version für das Optimistic Locking und einiges mehr. Würde Roo diese Eigenschaften direkt in die Entität hineingenerieren, müsste man später beim manuellen Editieren aufpassen, dass man diese Codestellen nicht ändert oder gar löscht. Daher erzeugt Roo sogenannte AspectJ Inter-Type Declarations. Sie enthalten zusätzliche Methoden und Klassenvariablen wie z.B. die ID. Beim Kompilieren werden sie durch AspectJ in die eigentlich Klasse eingewebt. Das Ergebnis ist dann ganz normaler Java-Bytecode. Der Vorteil ist, dass Roo diese Dateien erstellen, ändern und löschen kann, ohne dass der Entwickler dadurch beeinflusst wird. Er wird diese Dateien nie ändern, kann aber die Entitäten beliebig weiterentwickeln. Bei einem Versions-Upgrade von Roo kann so auch sämtlicher generierter Code auf den neusten Stand gebracht werden, ohne dass der selbstgeschriebene Code davon beeinflusst wird.

Außerdem werden die Domänenklassen so vollständig von solchen technischen Belangen frei gehalten. Sie enthalten nur die reinen Daten und die Geschäftslogik. Dadurch kann man zum Beispiel Persistenz-Technologie sehr leicht ändern.

Jetzt aber wieder zurück zu unserer Domänenklasse: Wir werden jetzt mit Roo noch die Eigenschaften hinzufügen:

  1. roo> field string --fieldName employee --notNull --sizeMin 1 --sizeMax 20
  2. roo> field date --fieldName fromDate --notNull --type java.util.Date
  3. roo> field date --fieldName toDate --notNull --type java.util.Date
  4. roo> field string --fieldName comment --sizeMax 200

Auch hier kann die Tabulator-Taste wieder helfen.

Wenn wir jetzt die Klasse HolidayRequest öffnen, sollte sie wie in Listing 1 aussehen. Sie enthält die angegeben Eigenschaften, sowie die JPA-Annotationen und die Bean-Validation-Annotationen (JSR-303). Es fehlen allerdings die Getter- und Setter-Methoden und auch die toString()-Methode. Sie wurden von Roo automatisch in den .aj-Dateien eingefügt, sodass sie zur Laufzeit zur Verfügung stehen. Durch die AspectJ Developer Tools, welche bereits in STS enthalten sind, funktioniert in Eclipse auch die Code-Vervollständigung für diese Methoden. Würden wir jetzt weitere Eigenschaften direkt in der Klasse einfügen oder löschen, würde Roo auch die Getter und Setter-Methoden sowie die toString()-Methode anpassen. Vorraussetzung ist nur, dass Roo einmal nach der Änderung gestartet wird oder während der Änderung läuft. Man könnte die Änderung sogar mit dem vi (bzw. unter Windows Notepad.exe) vornehmen ;-).

  1. @Entity
  2. @RooJavaBean
  3. @RooToString
  4. @RooEntity
  5. public class HolidayRequest {
  6. @NotNull
  7. @Size(min = 1, max = 20)
  8. private String employee;
  9. @NotNull
  10. @Temporal(TemporalType.TIMESTAMP)
  11. private Date fromDate;
  12. @NotNull
  13. @Temporal(TemporalType.TIMESTAMP)
  14. private Date toDate;
  15. @Size(max = 200)
  16. private String comment;
  17. }

Wieso mussten wir eigentlich die Klasse gar nicht angeben? Weil Roo automatisch die zuletzt erstellt Klasse verwendet. Hat man Roo zwischendurch beendet oder will man einer anderen Klasse Eigenschaften hinzufügen, dann muss man die Klasse mit dem Argument "--class" angeben.

Und wo ist das DAO bzw. Repository? Bei Roo wird direkt der JPA EntityManager verwendet, allerdings innerhalb der Domänenklasse. Das heißt, unsere Klasse HolidayRequest hat statische Methoden wie findHolidayRequest(long id), findAllHolidayRequests() und countHolidayRequests(), welche ebenfalls über AspectJ eingewebt werden, später werden wir dann noch zusätzliche Finder-Methoden hinzufügen. Eine konkrete Instanz von HolidayRequest hat unter anderem die Methoden persist(),merge() und remove(). Dieses Konzept stammt aus dem Buch Domain Driven Design und wird sehr häufig in der Praxis verwendet.

Und was ist mit den Tests? Die kann man sogar auch mit Roo erzeugen lassen:

  1. roo> test integration

Es werden dabei die oben beschriebenen Methoden der Domämenklasse gegen die Datenbank getestet. Auch diese Testmethoden werden über AspectJ eingewebt, sodass wir die Testklasse mit spezifischeren Tests erweitern können. Über den Sinn und Unsinn solcher generierten Tests (für wiederum generierten Code) kann man natürlich streiten.

Teil 1   Teil 2   Teil 3   Teil 4   

Anzeige

Kommentare

Gravatar Dierk König 06.10.2009
um 21:29 Uhr
"willommen zu hra" hat gleich zwei Fehler: 1: S 'k' fehlt 2. Grammatik. #zitieren

Anzeige

zurück zum Seitenanfang