Abstrakte Basisklasse für alle Entities?

[deamon]

Hallo,

jede Entity-Klasse braucht eine ID und bei optimistischer Sperrung auch noch ein Attribut für die Version. Statt das in jeder Klasse zu wiederholen, könnte man doch auch die gute, alte Vererbung benutzen:

@Entity
public abstract class Entity {
  @Id  private long id;
  @Version private long version;
}

Aber ist das eine gute Idee? Zum einen gibt es in Java nur einfache Vererbung, so dass es problematisch wird, wenn ein Entity von einem Nicht-Entity erben sollte, aber ich denke, das dürfte nicht so oft vorkommen. Und selbst wenn, könnte man dann immer noch die beiden Felder direkt in die Klasse schreiben. Und zum anderen werden Annotationen nur auf Klassenebene vererbt. Ich bin mir aber gerade nicht sicher, ob das hier ein Problem wäre, denn es wird ja auch das (annotierte) Feld der Oberklasse verwendet.

Hätte eine von Entity abgeleitete Klasse eine von JPA erkannte ID, wenn man es in der Klasse Entity so schreiben würde? Gibt es sonst noch Einwände oder bessere Vorschläge?

 

[FArt]

Mehrfachvererbung ist in jedem Fall unnötig.
Eine abstrakte Klasse ist ok.

Schau mal hier:
Decorator ? Wikipedia
Strategie (Entwurfsmuster) ? Wikipedia

 

[deamon]

Die beiden Entwurfsmuster kenne ich, aber wie sollten die hier helfen? Für jedes Entity einen Dekorator zu erzeugen und es so mit Attributen für id und version zu versehen, halte ich für extrem aufwändig, wartungsintensive und auch noch schlecht für die Performance (auch wenn das in der Praxis vielleicht nicht so wild wäre). Wie mir das Strategie-Entwurfsmuster helfen sollte, ist mir noch unklarer. Wie meinst du das?

Ein Problem mit meinem Ansatz ist mir übrigens noch eingefallen. Je nach dem, wie man eine Klassenhierarchie auf Tabellen verteilt, macht es sich nicht gut, eine zusätzliche Hierarchieebene für zwei Attribute einzuführen. Denn das würde bei dem Schema JOINED bedeuten, dass man einen Join mehr braucht. Java Persistent Objects - JPA Inheritance Aber so lange man diesen Fall nicht hat, sehe ich bisher nichts, was dagegen spräche.

 

[maki]

Ein Problem mit meinem Ansatz ist mir übrigens noch eingefallen. Je nach dem, wie man eine Klassenhierarchie auf Tabellen verteilt, macht es sich nicht gut, eine zusätzliche Hierarchieebene für zwei Attribute einzuführen. Denn das würde bei dem Schema JOINED bedeuten, dass man einen Join mehr braucht. Java Persistent Objects - JPA Inheritance Aber so lange man diesen Fall nicht hat, sehe ich bisher nichts, was dagegen spräche.

In so einem Fall würde man wohl nicht JOINED sondern SINGLE TABLE nehmen.
Trotzdem wäre es wohl besser, das nicht so zu machen imho.
@Version wird ja wohl nicht immer gebraucht, und wegen einem Attribnut extra eine Elternklasse einzufügen ist etwas übertrieben imho.