Cześć,
Czy zawsze warto mapować wszystkie relacje używając hibernate? Przykładowa sytuacja, mam klasę reprezentującą Userów w aplikacji, do tabeli Users za pomocą FK jest "podłączone" bardzo wiele innych tabel. Gdybym chciał mapować każdą relację, moja klasa znacząco spuchnie. Co zrobić w takiej sytuacji? Czy nie lepiej w każdej "podrzędnej" klasie na sztywno umieścić userId? Przy takim podejściu nie muszę za każdym razem modyfikować klasy usera gdy dojdzie mi jakaś tabela podrzędna. Czy mam racje? Czy są sytuacje w których lepiej nie mapować relacji, jeżeli tak, to jakie? Jestem poczatkujący w te klocki, dlatego pytam.
- Rejestracja:ponad 5 lat
- Ostatnio:ponad 3 lata
- Postów:7
0
Java 
Hibernate - Rejestracja:około 12 lat
- Ostatnio:około 9 godzin
- Postów:1431
2
Nikt nie każe Ci mapować wszystkiego w obie strony, jeśli z usera nie zamierzasz wyciągać powiązanych danych. Poza tym używasz niepoprawnych terminów, relacja jest synonimem słowa tabela, to o czym mówisz to związek lub powiązanie.
koszalek-opalek
+ za rozróżnienie relacji od powiązania! :)
- Rejestracja:ponad 6 lat
- Ostatnio:prawie 3 lata
- Postów:66
0
Każde mapowanie ma dwie strony, więc teoretycznie nie musisz mapować wszystkich powiązań po stronie encji User. (tzw. mapowanie odwrotne)
Problem pojawia się gdy chcesz np. usunąć encję. Dzięki mapowaniu odwrotnym hibernate odczepi encję od innych, a bez tego baza nie pozwoli tak po prostu usunąć, zgłaszając naruszenie FK.
Inną wadą jest to, że nie napiszesz w HQL "user.aukcja.cena" bo Hibernate nie "zobaczy" takiej ścieżki.
edytowany 1x, ostatnio: Tig
- Rejestracja:ponad 4 lata
- Ostatnio:około 2 lata
- Lokalizacja:Warszawa
- Postów:1092
3
Ja bym zadał pytanie: czy warto (zawsze) stosować JPA?
Inną wadą jest to, że nie napiszesz w HQL "user.aukcja.cena" bo Hibernate nie "zobaczy" takiej ścieżki.
Zobaczysz za to w SQL
edytowany 1x, ostatnio: scibi_92
- Rejestracja:prawie 7 lat
- Ostatnio:około 7 godzin
- Lokalizacja:Kraków
- Postów:1999
3
Ja bym się w takiej sytuacji nie martwił puchnięciem klasy (prawdopodobnie to i tak proste pojo i parę adnotacji z JPA i Lomboka)
Martwił bym się tym, żeby przy okazji nie trzasnąć sobie eager loading w Hibernate i nie wyciągać każdorazowo całej dżungli, gdy potrzebny jest banan :)
Przy okazji, jak już kombinujesz przy tym, co ma być w bazie a co w klasach - pomyślałbym, czy warto dawać Hibernate grzebać w schemacie bazy, czy nie ograniczyć jego mocy do weryfikowania że pasuje do modeli - a zarządzanie schemą zostawić liquibase, flyway lub czemuś innemu co potrafi np. zrobić rollback i trzymać historię zmian.
edytowany 2x, ostatnio: superdurszlak
- Rejestracja:ponad 4 lata
- Ostatnio:około 2 miesiące
- Postów:30
0
Programowanie obiektowe to nie tylko dziedziczenie, ale też agregacja. Użytkownik w aplikacji posiada różne adresy, np. adres zamieszkania, zameldowania, korespondencyjny. Jakbyś projektował aplikację i jeszcze nic byś nie wiedział o integracji z bazą danych, tylko obiekty mają żyć sobie w pamięci systemu, to naturalne byłoby stworzenie klasy użytkownika z polem typu kolekcja adresów. Ale jak zaczniemy projektować aplikację od strony bazy danych, to nagle programista zaczyna na klasie typu adres dawać pole typu użytkownik, bo już zaczyna przenosić logikę mapowania relacji z bazy danych do obiektu. A tym ma zająć się właśnie Hibernate, to on jest frameworkiem mapowania obiektowo-relacyjnym, piszesz obiektowo, mapuje się automagicznie na relacje w bazie danych. Moim zdaniem najczęściej mapowanie w Hibernate powinno robić się jednokierunkowe. Oczywiście takie podejście ma pewne minusy, niektóre zapytania są trudniejsze do napisania, ale za to łatwiej manipulować obiektami zarządzanymi w transakcji, nie trzeba tego robić z dwóch stron, skoro relacje są jednokierunkowe.