# JPA / Hibernate Annotations



## klara (30. Sep 2012)

Guten Morgen,

Gleich vorweg, ich bin gerade dabei mich in JPA / Hibernate einzuarbeiten.

Ich möchte ein bestehendes Java-Programm erweitern und die Daten persistent abspeichern. Die einzelnen Klassen die ich persistent abspeichern möchte, wollte ich nicht antasten bzw. diese enthalten auch sehr viel Logik. Somit dachte ich mir, dass vernünftigste ist es, eine neue Klasssen zu definieren die nur die entsprechenden Properties enthalten. Die Werte der Properties würde ich dann den eigentlichen Klassen übergeben.

Ist dies der richtige Ansazt oder soll ich die bestehenden Klassen antasten?

Bei meinem Ansatz taucht aber nun folgendes Problem auf.

In dem Buch Java Persistence with Hibernate haben die so ein ähnliches Problem:
Es gibt eine abstrakte Klasse BillingDetails von der zwei weitere Klassen CreditCard und BankAccount abgeleitet sind. 
In diesem Buch haben sie dies mit @MappedSuperclass gelöst. 

Das Problem ist, da ich nicht mit den eigentlichen Klassen arbeite, müsste ich mit Reflections arbeiten und falls es eine CreditCard ist die entsprechende Klasse CreditCard laden.

Gibt es da eine andere Lösung?

Ich hoffe ich war nicht zu konfus. Falls es doch der Fall war, bitte nochmals nachfragen. Ich hab derzeit wirklich keinen Plan wie ich dies vernünftig löse. :noe:

Danke im Voraus
Klara


----------



## Ullenboom (30. Sep 2012)

Es ist sonst noch möglich weiterhin deklarativ die Mapping-Details in einer XML-Datei abzubilden. Jetzt wo es Annotationen gibt, haben wir schon verlernt, dass es auch noch anders geht 
Wenn du diesen Weg gehen möchtest, Google mal nach "JPA XML orm.xml".


----------



## klara (30. Sep 2012)

Hallo Ullenboom,

danke für deine Antwort. Ich habe mir jetzt etwas orm.xml angeschaut. 
Auch wenn ich statt Annotationen die orm.xml verwenden würde, müsste ich die bestehenden Klassen ändern (setter alle public machen, leeren Konstruktor einfügen...).

@Nachtrag: Bzw. auch final Variablen werden verwendet. 

Jetzt bin ich mir nicht ganz im Klaren, was vernünftiger ist. Soll ich die bestehenden Klassen abändern oder meinen Ansatz weiterfolgen?

Nur wie löse ich dann das Problem mit der Klasse als Übergabeparameter am vernünftigsten. :noe:

Danke Klara


----------



## Ullenboom (30. Sep 2012)

JPA kann (wie auch JAXB) entweder die Werte aus den Attributen nehmen oder eben aus den Bean-Setter/Gettern. Siehe Access (Java EE 6 ). Das wäre nicht das Problem. Ohne einen Default-Constructor kommst du aber nicht hin. Daher wäre ein Delegete-Wrapper vielleicht ganz gut.

@Entity
public class EntityDelegate {
 private MyEntityICantChange stupidEntityICantChange;

 public EntityDelegate() {
  stupidEntityICantChange = new ... und initialisieren
 }

 public int getMyStuff() {
    return stupidEntityICantChange.getStuff();
 }

 Setter auch noch.
}

Hier kann dann JPA auf die Setter/Getter dran.

Wenn MyEntityICantChange Unterobjekte erzeugt wird das nur noch komplizierter. Daher würde ich vielleicht komplett auf die existierenden Klassen verzichten, und die JPA-Klassen komplett neu modellieren. Für die Business-Logik kann man dann die alten Beans aufbauen und dann an diese delegieren.


----------



## klara (30. Sep 2012)

Hallo Ullenboom,

herzlichen Dank für deine Antwort. Ich werde deinem Ratschlag folgen und die JPA-Klassen neu modulieren. 

Danke für deine Hilfe.

Klara


----------

