EJB Persistenz mit Java SE (3. Teil)

Bei der in diesem Artikel verwendeten Beispielanwendung, die hier als Download zur Verfügung steht, geht es um eine Lizenzverwaltung. Die Anforderungen für dieses Beispiel sind wie folgt definiert: Viele Anwendungen sind im Einsatz, jede Anwendung in unterschiedlichen Versionen, jede Version wiederum mit einer oder mehreren Lizenzen. Auf der anderen Seite stehen die Anwender, die diesen Lizenzen zugeordnet werden können. Es soll nun eine Anwendung erstellt werden, mit der alle diese Elemente verwaltet werden können.

Vorangegangene Artikel:

EJB-Persistenz mit Java SE
EJB Persistence mit Java Standard Edition (2. Teil)

Zuerst werden die Entities betrachtet. Sie sind als separates Paket erstellt, anstatt Bestandteil des Anwendungscodes zu sein. Es lohnt sich, auf diese Weise vorzugehen – in größeren Projekten kann man so die Entities als eigenes Projekt behandeln, was die Wiederverwendung in anderen Projekten vereinfacht. In der Beispielanwendung wurden vier Entities erzeugt, Application, Version, Licence und User. Die Besonderheiten der einzelnen Entities werden nun näher betrachtet.

In der Klasse Application gibt es eine 1:n-Beziehung zur Klasse Version. Im Folgenden ein Ausschnitt der Application-Methode, die Eigenschaften id und name werden übersprungen, da diese dem entsprechen, was bisher besprochen wurde.

Der mappedBy-Parameter wurde in den vorangegangenen Artikeln besprochen. Neu ist der Parameter cascade, der es der Persistenz-Engine ermöglicht, Operationen durchzuleiten und andere Tabellen in der Datenbank zu beeinflussen. Als Voreinstellung gibt es keine Kaskadierung, so dass Änderungen an einer Sammlung erfordern, dass der Inhalt der Sammlung explizit verwaltet wird. Wenn man die anderen Werte von CascadeType betrachtet, kann man die möglichen Operationen erkennen: ALL, PERSIST, MERGE, REMOVE, REFRESH. So werden mit der Einstellung CascadeType.PERSIST beispielsweise nur persistierende Objekte kaskadiert. Wenn eine neue Instanz einer Version der Versionsliste hinzugefügt wird, dann würde eine Aktualisierung der Instanz von Application durch Kaskadierung die neue Version in der darunterliegenden Datenbank speichern. CascadeType.MERGE wendet dieselbe Regel auf Updates und CascadeType.REMOVE auf Löschen innerhalb der Sammlung an. CascadeType.REFRESH löst das erneute Einlesen der Entitäten aus der Datenbank aus.