Wpis z mikrobloga

Kiedy tworzyć ścisłe relacje między encjami (np. one to many itd.) a kiedy opierać się na ich luźnych powiązaniach (np. tylko pole z id)? Załóżmy, że mamy encję User i encję Task. Można to zamodelować tak, że User jest w relacji one to many z Taskiem i ma w sobie listę tych tasków. Wtedy mamy jedno repozytorium User i jeśli chcemy pobrać taski danego Usera, to najpierw z repo pobieramy usera i potem z niego jego taski. Brzmi sensownie, ale pojawiają się pewnie problemy. Jest duży coupling między Userem a Taskiem. User nie potrzebuje przecież Tasków, żeby wykonać na nim jakieś operację biznesowę np. zmiana hasła czy zablokowanie konta. Z pojawianiem się kolejnych encji w jakiś sposób powiązanych z Userem, ten zaczyna puchnąć mając co raz więcej w sobie list do innych encji i metod. User może występować w różnych kontekstach a wiązanie go ściśle z jakaś encją ogranicza go tylko do jednego. Do tego dochodzi problem z wyznaczaniem granic modułów, bo w przypadku ścisłego powiązania taki np Task de facto powinien być podmodułem modułu User a jeśli postawimy na luźniejsze powiązanie, to mogą być to dwa oddzielne moduły komunikujące się tyko potrzebnymi informacjami przez fasady, dto np. czy user istnieje i można do niego dodać taska. Jakie podejście stosujecie?
#programowanie #naukaprogramowania #programista15k #java
  • 4
i jeśli chcemy pobrać taski danego Usera, to najpierw z repo pobieramy usera i potem z niego jego taski.


@Edelner:
To nie to? http://marcinszewczyk.pl/problem-n-plus-1/

Jest duży coupling między Userem a Taskiem


A na czym ten coupling polega? Przecież jak masz przy tworzeniu usera nie musisz mieć tasków

Z pojawianiem się kolejnych encji w jakiś sposób powiązanych z Userem, ten zaczyna puchnąć mając co raz więcej w sobie list do innych encji
@Edelner w relacji onetomany jak pobierzesz Usera to taski się nie zaciągną, bo onetomany jest domyślnie Lazy. Więc przy zmianie hasła nie zaciągnie Ci taskow jesli nie wywolasz user.getTasks()