Mam aplikację do zarządzania taskami przez zalogowanego usera (taka todolista na sterydach) i teraz pytanie - czy na pewno potrzeba tutaj relacji OneToMany między encją User i encją Task? Tworzy to dość silny coupling między modułami i utrudnia enkapsulację. Przecież apka działa tak, że user loguje się i zarządza swoimi taskami. Teraz to wygląda tak, że już po zalogowaniu jak np. user chce dodać taska, to ten user jest pobierany z repo i na nim jest wywoływana metoda addTask, bo ma w sobie listę swoich tasków w relacji OneToMany, a jeśli user nie istnieje, to zwracany jest błąd. Trochę bez sensu, bo przecież gdyby taki user nie istniał, to niemożliwe byłoby już samo zalogowanie się. Nie lepiej i prościej byłoby zrezygnować w ogóle z relacji (task miałby tylko id usera) i mieć oddzielne repo do Userów i Tasków? Jedyne problemy jakie widzę przy takim podejściu to możliwość zapisania taska do bazy z id usera, który nie istnieje. Można być postawić bardziej gólnee pytanie - czy relację bazodanowe nie są czasem nadużywane?
No jak nieistniejący user może mieć taski - to bez sensu co napisałeś.
To co napisałeś nie ma żadnego sensu. Pomijam kwestie że nie wiesz co znaczy relacja, ale idąc dalej nie rozumiem czemu wg ciebie logika musi być taka: ten user jest pobierany z repo i na nim jest wywoływana metoda addTask. Niby z czego to wynika? o_O Równie dobrze mógłbyś dodać taska i ustawić mu user id aktualnie zalogowanego użytkownika.
Twój problem polega na tym, że zamiast myśleć o logice aplikacji, to myślisz o jakimś JPA, a wiadomo ze jak masz w ręku młotek to nagle wszystko wygląda jak gwoździe :D Zapomnij na chwilę że masz tam jakieś JPA albo w ogóle bazę danych. Przemyśl jak ma wyglądać logika aplikacji a potem oznacz sobie które dane chciałbyś utrwalać.
Przecież już o to pytałeś: Relacje między encjami i ich granice
TL;DR tak, relacje bazodanowe są nadużywane
Pro tip: mozesz miec constraint FK na bazie danych bez modelowania tego w JPA :)
@Shalom:
To co napisałeś nie ma żadnego sensu. Pomijam kwestie że nie wiesz co znaczy relacja
Niby z czego to wywnioskowałeś?
ale idąc dalej nie rozumiem czemu wg ciebie logika musi być taka: ten user jest pobierany z repo i na nim jest wywoływana metoda addTask. Niby z czego to wynika? o_O
Bo user ma listę tasków w sobie? Właśnie myślę nad zmianą tego.
Równie dobrze mógłbyś dodać taska i ustawić mu user id aktualnie zalogowanego użytkownika.
No właśnie po to założyłem ten temat, żeby zapytać się które podejście jest lepsze. Też myślę, że to drugie z ustawianiem taskowi id zalogowanego usera.
Twój problem polega na tym, że zamiast myśleć o logice aplikacji, to myślisz o jakimś JPA
Nie, mi chodzi tylko o powiązanie między encjami. Równie dobrze mógłbym to zapisywać w pamięci w hashmapie i też bym stanął przed problemem, czy user na pewno musi mieć w sobie listę tasków.
Niby z czego to wywnioskowałeś?
z tego:
w relacji OneToMany
Bo user ma listę tasków w sobie? Właśnie myślę nad zmianą tego.
Ale to w ogóle nie ma żadnego znaczenia. Myślisz cały czas jakimś JPA zamiast myśleć o tym co aplikacja na robić i co zapisywać w bazie.
Nie, mi chodzi tylko o powiązanie między encjami. Równie dobrze mógłbym to zapisywać w pamięci w hashmapie i też bym stanął przed problemem, czy user na pewno musi mieć w sobie listę tasków.
No nie, bo jak zaczniesz myśleć o domenie o nie o JPA to dojdziesz do tego że User może być reprezentowany przez wiele różnych klas, w zalezności od use-case który jest realizowany. To nie jest tak, że w systemie może być tylko jedna klasa User i musi obsłużyć wszystkie możliwe operacje.
Sampeteq napisał(a):
Można być postawić bardziej gólnee pytanie - czy relację bazodanowe nie są czasem nadużywane?
To o czym piszesz to nie są relacje bazodanowe. To o czym piszesz to są problemy z nadyżywaniem JPA. Relacje bazodanowe to są tabelki, chociaż durnie to brzmi. A wynika to z tego że terminologię relacyjnych baz danych stworzyli matematycy