Konwersja Entity na wiele DTO

Odpowiedz Nowy wątek
2018-10-29 08:52
eL
0

Cześć.
Mam projekt w którym zapisuje Userów do bazy, W RESTowym API przyjmuje np. UserDTO, przepuszczam to potem w serwisie przez UserConverter i na wyjściu otrzymując Entity zapisuje to do bazy. Żeby obsłużyć zapytanie o rejestrację użytkownika potrzebuje więc klasę DTO, Entity i konwerter który zamienia w obie strony.
Teraz powiedzmy że chciałbym pobrać użytkownika (np. żeby wyświetlić stronę z ustawieniami użytkownika). Część pól z poprzedniego UserDTO nie jest mi już potrzebna więc jedyne co zauwazam to dodanie kolejnego DTO i następny konwerter.
Ma to w ogóle sens? Za chwile okaże się że mam wiele DTOsów i konwerterów które niewiele się od siebie różnią. Druga sprawa że modyfikując Entity może się okazać że wszystkie te konwertery będę musiał aktualizować...
Jakiś pomysł jak coś takiego sensownie obsługiwać?
Ps. Projekt pisany w Javie ale problem jest raczej ogólny więc język nie ma tu chyba większego znaczenia.

Pozdrawiam

edytowany 1x, ostatnio: eL, 2018-10-29 08:53

Pozostało 580 znaków

2018-10-30 07:13
eL
0
Aleksander Brzozowski napisał(a):
Bambo napisał(a):

Ja dla każdego widoku na froncie mam osobnego dtosa, ale nie muszę już nic mapować z encji - jeśli muszę coś popchać po prostu do klienta, nie updatuje mi to stanu aplikacji to wyciągam z bazy dtosa bezpośrednio przez jakiś query service i wypycham restem. Poczytaj o CQRS i JOOQ.

Też staram się tak robić, szczególnie kiedy posiada się lomboka, to zrobienie tych dto jest bardzo proste i szybkie.
Jeżeli jakaś encja może posiadać kilka stanów, którym odpowiadają różne dto, to zrobiłbym ich tyle ile trzeba.

Wcześniej myślalem że robienie wielu DTO + konwerter dla każdego z widoków jest głupie bo sporo kodu podobnego powstaje ale z drugiej strony jak czytam że inni tak robią to zaczynam się sam zastanawiać że to w sumie może mieć sens i jest przynajmniej bardziej czytelne niż kombinowanie z jakimś jednym DTO żeby go na kilka widoków użyć.

Mam lomboka i buildera w projekcie i moje konwertery tak budują DTO albo Entity.
Mógłbym pozbyć się konwerterów i tworzyć te obiekty przez buildera w miejscach gdzie to potrzebuje, natomiast niektóre klasy są bardzo rozbudowane więc wolę to zamknąc w konwerterach.

Generalnie z tego co rozumiem to pomijając sposób z JOOQ (bo niestety już mam jpa w projekcie) to zostaje mi to samemu konwertować albo zrobić jakieś projekcje itp. i tak czy inaczej nie ma na to jakiegoś sprytnego wzorca który by pozwolił nie klepać aż tyle kodu a jednocześnie byłby bardzo czytelny.

Pozostało 580 znaków

2018-10-30 08:55
2

Wydziel grupy pól które się powtarzają.
Np. w UserProfileDTO wydziel sobie atrybut UserDTO user, w którym masz te powtarzające się dane np. username, avatar.

Jeśli chcesz, żeby struktura zserializowanego w JSONie UserProfileDTO była płaska (np. nie chcesz pola user, tylko od razu username, password), to używasz adnotacji @JsonUnwrapped

Potem możesz sobie ten UserDTO tak samo komponować do innych DTO.

edytowany 2x, ostatnio: qbns, 2018-10-30 08:57

Pozostało 580 znaków

2018-10-30 15:54
eL
0

Okej, dzięki bardzo!
Myślę że konwertery i pomysł @qbns są dla mnie wystarczające. Przy pobieraniu danych z bazy jeśli się okażę że sporo kolumn w danym momencie nie jest potrzebne to żeby nie zaciągać za dużo danych będę po prostu dodawać projekcje albo widoki. Tak czy inaczej myślałem że znajdę jedno konkretne rozwiązanie które będzie uniwersalne dla wszystkich przypadków ale jednak okazuje się że lepiej będzie mixować je w zależności od potrzeb. Dzięki.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0