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

Microsoft nennt weitere Details zu kostenpflichtigen Patches für Windows 10

Erstmals liegen Preise für Verbraucher vor. Sie zahlen weniger als Geschäftskunden. Dafür beschränkt Microsoft den…

6 Stunden ago

Microsoft verschiebt erneut Copilot Recall

Die Entwickler arbeiten noch an weiteren „Verfeinerungen“. Windows Insider erhalten nun wohl eine erste Vorschau…

1 Tag ago

GenKI im Job: Mitarbeitende schaffen Tatsachen

Laut Bitkom-Umfrage werden in jedem dritten Unternehmen in Deutschland private KI-Zugänge genutzt. Tendenz steigend.

1 Tag ago

97 Prozent der Großunternehmen melden Cyber-Vorfälle

2023 erlitten neun von zehn Unternehmen in der DACH-Region Umsatzverluste und Kurseinbrüche in Folge von…

1 Tag ago

„Pacific Rim“-Report: riesiges, gegnerisches Angriffs-Ökosystem

Der Report „Pacific Rim“ von Sophos beschreibt Katz-und-Maus-Spiel aus Angriffs- und Verteidigungsoperationen mit staatlich unterstützten…

1 Tag ago

DeepL setzt erstmals auf NVIDIA DGX SuperPOD mit DGX GB200-Systemen

NVIDIA DGX SuperPOD soll voraussichtlich Mitte 2025 in Betrieb genommen und für Forschungsberechnungen genutzt werden.

1 Tag ago