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:

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.

Page: 1 2 3 4

ZDNet.de Redaktion

Recent Posts

Salesforce: Mit Einstein GPT zurück auf die Überholspur?

Salesforce forciert den Ausbau seiner Industry Clouds. Mit ihrem Prozesswissen könnten deutsche IT-Dienstleister davon profitieren.

9 Minuten ago

Neue Backdoor: Bedrohung durch Malvertising-Kampagne mit MadMxShell

Bisher unbekannter Bedrohungsakteur versucht über gefälschte IP Scanner Software-Domänen Zugriff auf IT-Umgebungen zu erlangen.

1 Tag ago

BSI-Studie: Wie KI die Bedrohungslandschaft verändert

Der Bericht zeigt bereits nutzbare Angriffsanwendungen und bewertet die Risiken, die davon ausgehen.

2 Tagen ago

KI-Wandel: Welche Berufe sich am stärksten verändern

Deutsche sehen Finanzwesen und IT im Zentrum der KI-Transformation. Justiz und Militär hingegen werden deutlich…

2 Tagen ago

Wie ein Unternehmen, das Sie noch nicht kennen, eine Revolution in der Cloud-Speicherung anführt

Cubbit ist das weltweit erste Unternehmen, das Cloud-Objektspeicher anbietet. Es wurde 2016 gegründet und bedient…

2 Tagen ago

Dirty Stream: Microsoft entdeckt neuartige Angriffe auf Android-Apps

Unbefugte können Schadcode einschleusen und ausführen. Auslöser ist eine fehlerhafte Implementierung einer Android-Funktion.

2 Tagen ago