JPA Einführung: Entity Klassen

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.

Ein Beispiel für eine einfache Entitätsklasse

@Entity
public class Person {
@Id
@GeneratedValue
private Long id;
private String vorname;
private String nachname;
// default constructor
public Person () {
}
// getter + setter
}

Die @Entity Annotation macht kenntlich, dass diese Klasse von JPA persistiert werden soll, @Id kennzeichnet den Primärschluessel und @GeneratedValue bedeutet, dass dieser automatisch generiert werden soll (also ein synthetischer Primärschlüssel).
Mit diesen wenigen Angaben ist bereits erreicht, dass Objekte der Person Klasse persistiert werden können – lediglich die Konfiguration der Datenbank für JPA fehlt noch. Die genaue Steuerung in welche Tabellen/Spalten die Speicherung in der Datenbank erfolgt ist optional, und wird ohne zusätzliche Konfiguration mit Default-Werten realisiert.

JPA persistence.xml Konfiguration

In der Datei „persistence.xml“ (normalerweise im META-INF Verzeichnis) befindet sich die Datenbankkonfiguration fuer den JPA Provider.
Ein verkürztes Beispiel passende zu der Beispiel-Entität von oben:
<persistence xmln="http://java.sun.com/xml/ns/persistence" ... >
<persistence-unit name="addressbook">
<class>com.example.domain.Person</class>
<properties>
<property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver" />
...
</properties>
</persistence-unit>
</persistence>
Zuerst erfolgt die Angabe des symbolischen Namens unter welchem diese Konfiguration verfügbar gemacht wird, dann folgt welche Klasse(n) zu persistieren sind (falls diese nicht per @Entity bereits deklariert sind, je nach JPA Provider reicht die @Entity Annotation nicht aus) und schließlich die Konfiguration der Datenbankverbindung ueber den JPA Provider Hibernate.
Theoretisch sind verschiedene Persistence-Units möglich, ebenso kann über <provider> explizit der JPA Provider konfiguriert werden. In der Praxis findet sich jedoch für eine Anwendung in der Regel eine Persistence Unit und lediglich eine JPA Implementierung, die dann auch standardmäßig verwendet wird.
Die Properties des JPA Providers sind dabei spezifisch für den jeweiligen Provider – in diesem Fall Hibernate.

Objekt mittels JPA speichern

Nun fehlt nur noch, dass ein Entity Object mittels JPA auch gespeichert wird. Nachdem die Vorarbeiten erledigt sind, zeigt sich schnell wie einfach die Arbeit Objekte zu speichern und zu laden dank JPA wird:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("addressbook" ); //der symbolische Name
EntityManager em = emf .createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin ()
Person p = new Person ();
...
em.persist(p);
tx.commit();
em.close();
Im nächsten Teil folgt dann wie Objekte aus der Datenbank geladen, geändert und auch gelöscht werden können.