Hibernate - podstawy - dziedziczenie encji

Siemka,

Trochę mi wstyd że o takie rzeczy pytam, ale już kilka godzin nad tym siedzę i już mi mózg powoli paruje.

Otóż mam encję Base z polami a, b, c, d, a także encję Extended z polami e, f, g. No siłą rzeczy, tak już zamodelowałem, że Extended JEST Base, i class Extended extends Base. Projekt typowy enterprise, mapuję na bazę Oracle na dwie tabelki - w jednej mam bazodanowe pola a, b, c, d, a w drugiej pola e, f, g oraz fk na pierwszą tabelę. Zdecydowałem, że jeśli jest jakiś obiekt typu Extended jest persystowany, to ma rekord w tabeli BASE oraz rekord w tabeli EXTENDED. No okej, przechodzimy do javy:

class Extended extends Base

No i według https://www.baeldung.com/hibernate-inheritance pasuje mi, żebym użył strategii Joined Table.
Dodaję do tego Springowe CRUDowe repository dla typu Base.

Jednak tak się zastanowiłem, że w końcu powinniśmy wybierać kompozycję zamiast dziedziczenia, i wymyśliłem sobie inne podejście:

a) klasa Extended nie rozszerza tej klasy Base - jest zwykłą encją
b) w Extended jest pole typu Base, oznaczone jako @Delegate z lomboka
b) zarówno Extended jak i Base implementują interfejs CommonInterface (nazwa interfejsu tutaj mniej ważna)
c) Interfejs CommonInterface zawiera w sobie wszystkie metody z klasy Base
d) Są 2 różne Springowe CRUD repozytoria - osobno dla Base i osobno dla Extended

Co sądzicie, które podejście "lepsze"? Bo mam już ból głowy i możliwe że wymyślam jakieś głupoty :D

Dałeś tak mało danych i tak bardzo wyprałeś to z kontekstu że jedną możliwą odpowiedzią może być To zależy.
Ale jako były brydżysta odpowiem 40-60 i strzelę że w 40% wypadków lepsze będzie dziedziczenie, a w 60% wypadków kompozycja. Zwyczajnie za mało danych żeby powiedzieć coś sensownego :(

KamilAdam napisał(a):

Dałeś tak mało danych i tak bardzo wyprałeś to z kontekstu że jedną możliwą odpowiedzią może być To zależy.

Okej, masz rację. Natomiast chodzi mi po prostu o taką zdroworozsądkową opinię - Czy mogę zastąpić dziedziczenie dwóch ENCJI na implementowanie wspólnego interfejsu? I czy to później ma oddziaływanie na Springowe CRUDowe repozytoria?

1. Po co Ci dziedziczenie
2. Poczytaj o @MappedSuperclass
3. Rozdziel model encji od modelu domenowego (w tym drugim możesz sobie wprowadzić interfejs, cokolwiek chcesz)
4. Wyrzuć Lomboka

Charles_Ray napisał(a):

1. Po co Ci dziedziczenie

Mam sytuację wręcz typową dla dziedziczenia, jednak właśnie podrzucam pomysł jak to zrobić kompozycją zamiast dziedziczenia. Tylko nie wiem czy jest to good idea

1. Poczytaj o @MappedSuperclass

To jest jedna ze strategii mapowania dziedziczenia w JPA. jednak nie urządza mnie ona - zakłada brak tabeli dla super klasy. W moim przypadku, chcę tabelę zarówno dla super jak i subklasy, czyli w tym przypadku strategia Joined Table byłaby bardziej właściwa.

1. Wyrzuć Lomboka

Dlaczego? Nie trzeba pisać sporo boilerplatu

Zadanie JEST z JPA, to się nie zmieni.

Dziedziczenie nie jest obojętne vs kompozycja
Trzeba mieć możliwość kwerendy

 select Base 

która zwróci obiekty Base i Extended (bo Extended JEST Base).
EDIT:
ZTCW pomysł z extendowaniem interfejsu, elegancki w gołej javie, raczej nie da prawidłowego skutku w JPA

Wątek już dyskutuje jedną z trzech implementacji "extension table per class".
Każda z implementacji ma zady i walety.
W prostych tematach ja wybieram szeroką tabelę z selektorem, to się łatwo serwisuje w gołym SQL.

Pinek napisał(a):

d) Są 2 różne Springowe CRUD repozytoria - osobno dla Base i osobno dla Extended

Nigdy nie stawiałem sobie w ten sposób pytania, ale chyba NIEEEEEEEE