Konzeption der Persistenzlogik
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
Die Persistenzlogik beinhaltet das Datenmodell (d.h. Modellkomponenten, Entitäten und Attribute) der fachlichen Architektur und bildet dieses auf die technische Ebene ab. Sie gliedert sich, wie der Anwendungskern, in Fachkomponenten. Im Normalfall ist der Funktionsumfang dieser Fachkomponenten viel geringer als der Funktionsumfang der Entsprechungen im Anwendungskern. Dies liegt darin begründet, dass sich die Persistenzlogik ausschließlich um die Speicherung von Geschäftsobjekten in einer Datenbank kümmert und selbst keinerlei Geschäftslogik beinhaltet.
1. Grundlagen
Fachkomponenten bestehen aus einer Schnittstelle und den persistenten Objekten. Die Schnittstelle bildet in der Regel ein Data Access Object ab. Persistente Objekte werden Entitäten genannt.
Die folgende Abbildung zeigt den Aufbau einer Fachkomponente im Datenzugriff.
Ein Data Access Object (DAO) beschreibt die Schnittstelle der Fachkomponente, d.h. die Operationen, die zum Speichern und Lesen der Entitäten aus der Datenbank nötig sind.
Entitäten bilden Geschäftsobjekte ab und werden in der Regel nach ihnen benannt.
| Entität | |
|---|---|
Schema |
|
Beispiel |
|
Ein Persistenz-Klassenmodell ist das Modell der Entitäten, welche dauerhaft abgespeichert werden sollen.
2. Vorgaben für das Persistenz-Klassenmodell
Die folgenden Abschnitte beschreiben gewünschte Eigenschaften des Persistenz-Klassenmodells sowie Verwendungsregeln.
2.1. Persistenz-Klassenmodell und Datenbank-Schema sollen möglichst ähnlich sein
Im Idealfall wird jede Entität auf eine Tabelle des Datenbankschemas abgebildet. Eine solche Abbildung ist intuitiv und erleichtert das Verständnis der Anwendung und des Datenbankschemas, was wiederum in der Wartung ein großer Vorteil ist.
Tatsächlich ist es aus Gründen der Datenbankperformance aber oft erforderlich, von diesem Idealfall abzuweichen. Hier gilt es, auf möglichst wenige Tabellen zuzugreifen, um an die benötigten Informationen zu gelangen.
So ist es zum Beispiel sinnvoll, für 1:1-Beziehungen im Persistenz-Klassenmodell den Entitäten mit der Annotation @Embeddable zu versehen.
Somit wird der Inhalt einer Datenbanktabelle auf mehr als eine Entität verteilt.
Solche Entitäten können dann über das Lesen einer einzigen Tabellenzeile aus der Datenbank gefüllt werden.
2.2. Vererbung im Persistenz-Klassenmodell
Vererbungshierarchien können in relationalen Datenbanken nicht direkt umgesetzt werden. Die JPA-Spezifikation beschreibt deshalb mehrere Strategien des O/R-Mappings von Vererbungshierarchien. Sie werden im Baustein JPA/Hibernate zusammen mit Regeln für ihre Verwendung beschrieben.
Für alle Strategien gilt, dass die abzubildende Vererbungshierarchie nicht zu umfangreich sein sollte. Datenbankzugriffe auf Tabellen mit großen Hierarchien sind meistens wenig performant. Außerdem lässt sich die Vererbungshierarchie anhand der Datenbanktabellen entweder nicht oder nur schwer erkennen, und die Tabellen können unübersichtlich werden.
2.3. Fachlogik in Persistenzlogik vermeiden
Die Implementierung von fachlicher Logik in der gesamten Persistenzlogik, d.h. in den DAOs und Entitäten, ist zu vermeiden. Idealerweise sollten die Entitäten lediglich Getter- und Setter-Methoden für die persistierten Daten enthalten. Jegliche Fachlogik muss im Anwendungskern implementiert werden.
Zur Fachlogik gehören auch Validierungen.