JPA-Glossar
Die Java Persistence API (JPA) wurde im Zuge von EJB 3.0 spezifiziert. Da JPA sowohl im Java-EE- als auch im Java-SE-Umfeld einsetzbar ist, wurde sie in eine eigene Spezifikation ausgegliedert, d.h. Persistenz ist nicht mehr direkter Bestandteil von EJB. Wir haben diesem Umstand mit unserem JPA-Glossar Rechnung getragen. Es entzaubert und erklärt die vielen Fachbegriffe wie Fetching-Strategien, Detached Object, Multi-table Mapping etc. und erklärt, was hinter den Begrifflichkeiten steckt. Lesen Sie auch unser Buch EJB 3 komplett, in dem wir die Themen ausführlich erläutern.
Wenn Sie Begriffe vermissen, die Ihrer Meinung nach erklärt gehören oder falls Sie Fragen haben, mailen Sie uns doch einfach unter
Index
A·B·C·D·E·F·G·H·I·J·K·L·M·N·O·P·Q·R·S·T·U·V·W·X·Y·Z·Alle
| C nach oben | |
| Callback-Methoden | Um zu ermöglichen, sich in den Ablauf der Steuerung des Lebenszyklusses einer Persistent Entity einzuklinken, gibt es ein Set von vordefinierten Meta-Annotationen. Diese erlauben, beliebige Methoden in der Klasse zu kennzeichnen, sodass diese in Abhängigkeit der verwendeten Meta-Annotation zu definierten Zeitpunkten aufgerufen werden. Für das Einklinken in die Steuerung des Lebenszyklus von Persistent Entities stehen folgende Meta-Annotationen zur Verfügung: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpate und @PostLoad.
|
| Configuration by Exception | Ziele dieses Configuration by Exception-Ansatzes sind die Minimierung und die Reduzierung von Entwicklungszeiten und Aufwänden für die Konfiguration bzw. Entwicklung von Persistent Entities. Der Entwickler soll nur noch in Ausnahmefällen (daher: Configuration by Exception) konfigurierende oder laufzeitsteuernde Angaben für eine Persistent Entity vornehmen müssen. Nämlich nur in den Fällen, in denen das gewünschte Verhalten von dem definierten und vorgegebenen Standardverhalten abweicht. Es wird also das Ziel verfolgt, die Notwendigkeit der expliziten Angabe von Konfigurationsparametern für allgemein gültiges, erwartetes Verhalten und Anforderungen an die Persistence Provider Runtime zu minimieren bzw. zu reduzieren.
Konkret bedeutet dies, dass eine Menge von Funktionalitäten bzw. Verhaltensweisen per default voreingestellt sind. Dieses Defaultverhalten sollte den Großteil (80–90%) der typischen Anwendungsfälle abdecken. Trifft das Standardverhalten nicht das Anforderungsprofil, dann kann der Entwickler diese Standardwerte bzw. das Standardverhalten leicht übersteuern. Als Beispiel dafür sei angeführt, dass Persistent Entities per default einen Eager Load-Mechanismus verwenden. Will der Entwickler Lazy Load als Fetching-Strategie verwendet haben, muss er dieses explizit angeben. |
Copyright © 2008–2009 Holisticon AG
Dieses Glossar darf in vollständiger Form und unverändert jederzeit kopiert und kostenlos weitergegeben werden. Der Hinweis auf die Originalquelle http://www.holisticon.de/cms/JPAGlossar/Startseite muss ebenso wie dieser Copyright-Hinweis stets angegeben werden. Es ist nicht zulässig, das Glossar kommerziell zu vertreiben, gegen Entgelt weiterzugeben oder Inhalte zu verändern. Im Rahmen nicht-kommerzieller Verwendungen, beispielsweise Diplomarbeiten, darf das Glossar gerne übernommen werden. Die Verwendung in kommerziellen Zusammenhängen, beispielsweise in öffentlichen oder internen Schulungen, firmeninternen Netzwerken, Publikationen, Produkten etc. ist prinzipiell gestattet, wenn eine entsprechende Meldung an gesendet wird. Die Weitergabe ist sowohl in elektronischer als auch gedruckter Form zulässig. Im Internet zugängliche Kopien sind ebenfalls zu melden.
Hinweis zu den Urhebern der dargestellten Abbildungen: Alle hier wiedergegebenen Grafiken wurden von uns erstellt und sind NICHT von Dritten bezogen!
Nehmen Sie Kontakt mit uns auf!
Ihre Ansprechpartner:
| Stefan M. Heldt | Oliver Ihns |
| Telefon: +49 40 5074 2722 |