[Nofenak]

Czy DTO maja sens? Załóżmy, że mamy kilka DTO - do tworzenia encji, do updatu i do wyświetlania. Jeśli chcemy dodać jakieś pole, czy je usunąć czy zmienić to musimy to zrobić zazwyczaj w tych 3 DTO no i jeszcze w tej głównej encji domenowej, nie mówiąc, że konstruktory tych wszystkich obiektów mogą być użyte w jeszcze większej ilości miejsc. Jakby do tego dodać jeszcze oddzielanie encji biznesnowych od encji JPA to robi się kolejne miejsce, które trzeba zmodyfikować. Nie wygląda to za ciekawie. DTO są bardzo popularne, ale ostatnio tak nad tym myślałem i wydaje mi się, że w większości przypadków lepiej operować na tym jednym głównym obiekcie.
#programowanie #naukaprogramowania #programista15k #java

[stefan_pmp]

@Nofenak nie

[rolling_stone_with_no_hope]

@Nofenak: dto bez sensu i zawsze jest jednym z przyczynków do spaghetti code.

[aleksc]

@Nofenak: jak najbardziej tak, przecież to co jest w DTO do wyświetlania to nie musi być w DTO do insertu czy updatu. Zwykle DTO do wyświetlania ma więcej danych niż inne DTO. Poza tym encje w warstwie persystencji powinny być niezależne od DTO a nie wykorzystywane jako model tabeli w bazie, jako model do wyświetlania zwracany z kontrolera i model do update/insert przyjmowany w kontrolerze.

[JaTuTylkoPatrze123]

@Nofenak: DTO ma sens jeśli przesyłasz obiekty między modułami. Wtedy też są one kontraktem i możesz zmieniać encje bez konieczności zmian w innych modułach (ofc do pewnego stopnia). Dodatkowo DTO może zapewniać niemutowalnosc, więc żaden konsument nie narobi syfu.

[WhiskyRomeo]

@Nofenak: zdefiniuj "bounded context" i używaj wspólnego obiektu tylko w granicach tego kontekstu.

[aleksc]

dto bez sensu i zawsze jest jednym z przyczynków do spaghetti code.

@rolling_stone_with_no_hope: Miałem okazję pracować w projekcie, że był jeden model do wszystkiego, to była masakra, trzeba było dodać kolumnę w bazie danych więc i z automatu do tego modelu, potem jakieś cyrki robić w webformsach żeby daną propertę ignorować przy zapisie

[aleksc]

zdefiniuj "bounded context" i używaj wspólnego obiektu tylko w granicach tego kontekstu.

@WhiskyRomeo: ale ty piszesz teraz o czymś innym, że może być np. "produkt" w kontekście zamówienia i w kontekście oferty. A on pyta o DTO do wyświetlania czyli to co jest zwracane z kontrolera i do update/create czyli to co jest przyjmowane w kontrolerze.

[RobieInteres]

@Nofenak: Ostatnio spędziłem sporo czasu na szukaniu buga, bo ktoś korzystał z encji bazodanowej przesłanej z osobnego procesu i ją modyfikował pod tymczasowe obliczenia, a transakcja wciąż była otwarta. Tak się kończy korzystanie z encji bazodanowych, gdy w projekcie masz juniorów ( ͡° ͜ʖ ͡°)

[Nofenak]

@RobieInteres: Podział na encje domenowe i bazodanowe (np. JPA) jeszcze rozumiem, mi chodzi bardziej o mapowanie takiej czystej encji domenowej na dto właśnie.