Nachdem im ersten Teil der JPA Einführung die Infrastruktur für die Arbeit mit JPA fertig gestellt wurde, kommen wir nun zu den Entitätsklassen. Bei den Entities handelt es sich um ganz normale Java Klassen (POJOs), die kein spezielles Interface implementieren oder von einer vorgegebenen Oberklasse erben müssen. Lediglich ein default Konstruktor muss vorhanden sein.
Dank JPA Annotationen kann man erkennen, dass die Objekte persistiert werden.
Möchte man EJB3 konform arbeiten, so sollten die Annotationen dort angebracht werden, wo auf die Properties zugegriffen wird: An den Attributen für field-access, an den Getter-Methoden bei property-access. Dies sollte konsistent gemacht werden, und die beiden Formen sollten nicht gemischt werden. (Zwischen den beiden Formen wird über die Position der @Id Annotation unterschieden.)
Die Annotation der Attribute hat dabei den Vorteil, dass schnell erkennbar ist, was wie persistiert wird – kann jedoch bei einigen JPA Providern zu Performance Problemen führen. Auf der anderen Seite führen Getter-Methoden, die nicht zu persistierende Werte liefern und nicht explizit von der Persistierung ausgenommen werden zu möglicherweise schwer zu findenden Programmfehlern. weiterlesen
Schlagwort: hibernate
JPA Tutorial: JPA Einrichtung
JPA, die Java Persistence API bietet im Vergleich zu JDBC ein erhöhtes Abstraktionsniveau und ermöglicht damit in kurzer Zeit Anwendungen zu entwickeln, in denen Daten dauerhaft gespeichert werden müssen.
Zum Hintergrund von JPA: Bei dem Umgang mit Datenbanken gibt es schon sehr lange JDBC (Java Database connectivity) als einheitliche API um die Verbindung zu Datenbanken herzustellen. Auch hier handelt es sich bereits um eine einheitliche Schnittstelle, jedoch wird darüber lediglich festgelegt, wie Verbindungen aufgebaut werden, wie eine Abfrage eingeleitet wird und wie Transaktionen manuell gesteuert werden können.
Damit bleiben zwei Probleme: Der SQL Code muss von Hand erstellt werden, was gerade bei CRUD (Create, Update, Delete) Anwendungen viel Produktivität kostet, und zudem ist der SQL Code in der Regel herstellerabhängig. Ein Wechsel von Oracle zu Postgres bedeutet damit das Programm an vielen Stellen ändern zu müssen. Auch sind händisch erstellte Abfragen nicht immer optimal: Lazy loading von Entitäten, Caching Strategien und Transaktionssteuerung können sehr aufwendig werden. Dazu gesellen sich der relativ hohe Wartungsaufwand und die Gefahr von Fehlern die erst zur Laufzeit entdeckt werden. weiterlesen