Vererbung mit JPA / Hibernate - pro/contra

[JanHH]

Hallo,

habe gerade eine kleine "Meinungsverschiedenheit" mit meinem Projektleiter. Ich entwerfe Softwaremodelle so, wie ich es im Studium gelernt habe - ausgefeilt und sauber objektorientiert, mit einer fein granulierten Klassenhierarchie, relativ viel Vererbung, so dass jedes Objekt halt genau "seine" Funktionalität hat. Der Projektleiter neigt eher dazu, alles in eine Klasse zu stecken, und innerhalb dieser dann zu speichern, welche Funktion genau das Objekt hat, also Kram mit if, usw. Seine Argumentation ist, dass das mit Hibernate erhebliche Vorteile hat, er will so wenig Vererbung wie möglich in seinen Projekten.

Ich muss sagen dass er der "alte Hase" ist und ich eher der Anfänger. Er wird also wissen, was er tut. Aber vom Softwaredesign her widerspricht es halt dem, was ich gelernt habe und auch selber bevorzuge. Meiner Meinung nach sollte ein sauberes Modell im Vordergrund stehen, und Hibernate ist ein Werkzeug, um so ein Modell effizient auf eine Datenbank abzubilden. Keinesfalls sollte sich das Modell den Anforderungen von Hibernate wegen "verbiegen".

Was meint ihr dazu?

Gruß+Danke
Jam

 

[Gelöschtes Mitglied 5909]

Ich würde auch inheritance vermeiden und lieber composition verwenden, gilt aber nicht nur in verbindung mit JPA.

Wobei es bei JPA noch auf das Datenmodell ankommt bzw. den konkreten Fall (wenns ein neues Modell wird)

siehe z.B. Inheritance versus composition: Which one should you choose? - JavaWorld

 

[SlaterB]

eine Datenbank ist nicht objektorientiert, widerspricht es dir jetzt sie überhaupt zu benutzen?
irgendwo findet der Übergang zwischen DB und schicken sauberen Modell statt, Hibernate macht viel aber gewiss nicht alles,

wenn du es in vertretbaren Aufwand in einem Mapping direkt in die erste beteiligte Java-Klasse schaffst, dann gut,
ansonsten ist es kein Beinbruch, wenn es eine Java-Klasse/ -Schicht gibt, die nicht perfekt ist,
was soll ein JDBC-ResultSet von sich sagen?

 

[KSG9|sebastian]

Bei größeren Projekten/Datenmengen ist es völlig normal dass nicht immer die 3. Normalform verwendet wird. Genauso normal ist es dass Funktionalitäten zusammengezogen werden um eine bessere Performance zu erzielen.
Natürlich sollte man aufpassen dass das Datenmodel nicht verkommt - da ist einfach ein guter Mittelweg die Lösung.