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-29 09:09
0

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.

Pozostało 580 znaków

2018-10-29 09:22
eL
0
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.

Okej rzucę okiem.
U mnie problem jest jednak taki że mam hibernate'a (a w niektórych częściach jeszcze eksperymentalnie Spring Data JPA) i to samo w sobie wymusza już posiadanie klas Entity. Robiąc więc zwykłego select'a na wyjściu dostaję np. UserEntity które muszę przekonwertować żeby nie wypychać encji na widok. Czytałem artykuły tego typu:
https://smarterco.de/spring-data-jpa-query-result-to-dto/
z których wynika że można na wyjściu dostać DTO po zwykłym zrobieniu selecta ale takie egzotyczne rozwiązania mnie jakoś nie przekonują bo mam wrażenie że sprawdzają się tylko w prostych przypadkach.

Pozostało 580 znaków

2018-10-29 10:14
0

Dlatego staram się jpa nie używać :). Możesz też porobić sobie widoki zmaterializowane.

Pozostało 580 znaków

2018-10-29 11:37
eL
0

No tak, to prawda ale jednak wiele projektów hula na JPA i przypuszczam że do każdego select'a nie robi się widoków i jakoś to działa stąd też moje pytanie czy ma ktoś jakieś sprawdzone rozwiązania na to?

Pozostało 580 znaków

2018-10-29 12:00
0

Ja sobie chwalę to rozwiązanie które wcześniej podlinkowales, czyli używanie konstrukcji "select new dto(...) from".

Pozostało 580 znaków

2018-10-29 12:11
eL
0

A masz jakiś ciekawszy sposób niż tworzenie konstruktora ze wszystkimi polami i potem bindowanie to na zapytaniu?
W przypadku kilku pól nawet sobie wyobrażam użycie takie konstruktora natomiast jak mam powiedzmy klasę User, ona ma kilka pól typu imie, nazwisko itp oraz np. AdressDTO, SpecificDataDTO itp to musiałbym w tych wszystkich klasach dodatkowych też robić takie konstruktory i ten zwykły select byłby jakimś kosmicznie nieczytelnym tworem.

Pozostało 580 znaków

2018-10-29 14:33
0

Może projekcje ?

Pozostało 580 znaków

2018-10-29 14:58
0
eL napisał(a):

A masz jakiś ciekawszy sposób niż tworzenie konstruktora ze wszystkimi polami i potem bindowanie to na zapytaniu?
W przypadku kilku pól nawet sobie wyobrażam użycie takie konstruktora natomiast jak mam powiedzmy klasę User, ona ma kilka pól typu imie, nazwisko itp oraz np. AdressDTO, SpecificDataDTO itp to musiałbym w tych wszystkich klasach dodatkowych też robić takie konstruktory i ten zwykły select byłby jakimś kosmicznie nieczytelnym tworem.

Jak jest sporo konkretnych kolumn do pobrania to i tak zwykle trzeba je wszystkie wymienić w projekcji, więc dodanie samego wywołania konstruktora w zapytaniu nie wydaje mi się dużym problemem.
W przypadku gdy chcemy stworzyć kilka obiektów, zwykle robię to jak w odpowiedzi tutaj: https://stackoverflow.com/que[...]nate-hql-multiple-new-objects
Też mam trochę wątpliwości, czy to jest najlepsze rozwiązanie, ale zwykle wychodziło jako najkrótsze.

W przypadku gdy liczba kolumn do pobrania jest bardzo dużo, to zwykle kończę z widokiem przykrywającym zapytanie i osobnym mappingiem na widok.

edytowany 1x, ostatnio: Seti87, 2018-10-29 15:00

Pozostało 580 znaków

2018-10-29 21:32
0
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.

Pozostało 580 znaków

2018-10-29 21:41
0

A dlaczego nie używasz budowniczego? Jak masz lomboka to oznaczasz sobie klasę @Builder i nie musisz robić masy konwerterów, równie dobrze możesz zrobić taką mini fabrykę, gdzie po prostu uzupełniasz pola jakie chcesz. Tylko wtedy niektóre pola mogą przyjść jako 0 dla inta lub null dla obiektów/stringa więc na froncie musiałbyś sprawdzać czy jakiś element nie jest nullem.

Według tego podejścia to powinno się zrobić jedno dto, które posiada te same pola co encja, tylko niektóre są puste. To nie ma sensu, bo potem dostajesz taki model i zastanawiasz się czy to pole jest ustawione. - Aleksander Brzozowski 2018-10-29 21:44

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