Witam,
mam pytanie co do tworzenia DTO, jaki jest najlepszy sposób? Tworzyć swój mapper, korzystać z gotowych?
Ogólnie DTO przy JPA ma cel taki, żeby nam się transakcje nie nakładały, nie rzucać zbędnych danych z naszej normalnej domeny na front np. i bezpiecznie je oddzielać, tak?
Generalnie, u mnie, celem DTO jest ukrycie np. relacji z encji JPA, nie wysyłanie na front niepotrzebnych pól ewentualnie całkowita transformacja danych do formatu akceptowalnego przez front np. dwie encje JPA na jedną instancję klasy np. ViewModel albo coś.
Rozumiem, czyli jeśli mam encję (w sensie JPA - struktura danych) Customer, która ma w sobie relacje z Address oraz Account to powinienem mieć np. DTO dla usera, które wysyła dane o userze bez hasła np.? Nie ma co na siłę tworzyć DTO, gdy go nie potrzebuję, prawda?
Natomiast jak dobrze napisać DTO? Jak go mapować? Mógłby podać ktoś dobry przykład?
No i w jakiej warstwie odwoływać się do DTO, a w jakiej do mojej encji? (dao, controller, service)
Ja sugeruje podejscie takie, że poza Repozytorium nie ma obiektów @Entity, przemapowujesz je od razu na wyjściu do obiektów domenowych. A na wyjściu z kontrolera przemapowujesz na DTO, zeby zostawić tylko takie dane które chcesz wystawiać (ewentualnie kontroler od serwisów juz dostaje je w stakiej postaci jeśli potem tylko je przepycha dalej).
Hm, mówimy o Repozytorium w sensie DAO? Obiekt domenowy to taki, który zawiera też zachowania?
Repozytorium w sensie abstrakcji która ukrywa skąd się biorą/gdzie są zapisywane dane. DAO kojarzy mi się z takim typowo niskopoziomowym CRUDowym interfejsem a Repozytorium z czymś bliżej domeny.
Dla uproszczenia załóżmy, że hurr durr biznis aplikejszyn ma 3 główne warstwy (choć oczywiście veri sirius biznis enterprajs aplikejszyn może mieć ich dużo więcej):
Świat zewnętrzny interesuje tylko wysokopoziomowy aspekt Twojej aplikacji, klient żąda wykonania konkretnej operacji czy zwrócenia konkretnego wyniku. Encje pasują do opisywania rzeczywistości w ten sposób jak pięść do nosa. Gdy pytasz kogoś, czy zna Jadzię Kowalską i mógłby Ci dać jakiś kontakt do niej, chcesz dostać:
Dlatego tłumaczysz encje do DTO, w którym przekazujesz tylko te informacje, które są istotne w danym kontekście ;)
Jak już @Shalom i ktośtam jeszcze wspomniał, generalnie o te konwersje DTO <-> encja można się pokusić w dwóch miejscach:
Przy czym osobiście wolę już robić to w serwisie - jak wpakujesz te konwersje do kontrolera, to zaraz ktoś mądry przytroczy tam również część logiki, bo przecież i tak coś tam się już dzieje, no to jaki jest sens zmieniać w serwisie coś, co ma się dziać tylko przy wywołaniu danego endpointu etc. etc.... No ogólnie mam wrażenie, że z tym podejściem pokusa, by nababrać sobie w kodzie jest większa :D
W sumie w obecnym projekcie posunęliśmy się do tego, że samą translację DTO <-> encje przenieśliśmy poza właściwe serwisy, które tylko do niej sięgają i dostają gotowe obiekty, bez mieszania logiki aplikacji z translacją. Czy to dobre rozwiązanie? Nie wiem, pewnie nie, czas pokaże - choć póki co jakoś się jeszcze broni.
Rozumiem, można gdzieś o tym więcej poczytać? O takim podejściu? Jakieś blogi ciekawe, wystąpienia, artykuły? Jakieś osoby, które mądrze o tym mówią? Przykładu kodu? Bo chciałbym się lepiej zaznajomić z takim podejściem.. Typu obiekty domenowy, repozytoria itp.
O, dzięki ^, troszkę mi to rozjaśniło mi to jak te DTO używać. Czyli to normalne, że na jedną encje przypada nam kilka DTO? Czy raczej tworzymy to jako uniwersalne?
Teraz pytanie jak że zwykłej encji (JPA) stworzyć obiekt domenowy?
vizzini napisał(a):
Rozumiem, można gdzieś o tym więcej poczytać? O takim podejściu? Jakieś blogi ciekawe, wystąpienia, artykuły? Jakieś osoby, które mądrze o tym mówią? Przykładu kodu? Bo chciałbym się lepiej zaznajomić z takim podejściem.. Typu obiekty domenowy, repozytoria itp.
Nie jestem pewien, czy Martin pisze w Clean Code akurat o prawidłowym dzieleniu aplikacji na warstwy, bo CC ciągle czeka na przeczytanie gdzieś w odmętach dysku, ale tak czy owak możesz sięgnąć do tej książki - w sumie jak wygooglujesz "Clean Code pdf" to znajdziesz ją w jednym z pierwszych wyników
O, dzięki ^, troszkę mi to rozjaśniło mi to jak te DTO używać. Czyli to normalne, że na jedną encje przypada nam kilka DTO? Czy raczej tworzymy to jako uniwersalne?
Jak stworzysz uniwersalne DTO, które odpowie na potrzeby:
To wyjdzie Ci turbo-blob, który niezależnie od kontekstu będzie dostarczał 80% zbędnych informacji i 20% przydatnych :)
mozesz też w wolnej chwili
O, dużo rzeczy do nadrobienia..
Właśnie o tych warstwach, podejściach i wzorach muszę najwięcej poczytać.
Czy mogę gdzieś zobaczyć przykładowy kod z podziałem na: dto, encje i domeny biznesowe? Tak żeby one miały przy okazji jakieś relacje między sobą, a żebym mógł zobaczyć jak to dokładnie w środku wygląda?