Sprytna kopiarka do encji, DTO i podobnych

0

Czy jest jakaś biblioteka, która "sprytnie" kopiuje pola z DTO do encji itd ...
Oczekuję, że proste sytuacje skopiuje sama, a do ambitnych się robi jakiś override ...

Być może działa na zasadzie, że DTO trzeba obstawić jakimiś adnotacjami (bo encja ma swoje np JPA) ?

Jest takie coś? A może mam zmienić sposób myślenia o problemie?

2

Mapstruct?

0
Emdzej93 napisał(a):

Mapstruct?

Już czytam, i zarazem tu czekam na następne pomysły

0

modelmapper

0

dozer mapper

9

Nie robić tego wcale? ;) Widziałem w akcji kilka takich libek (jak mapstruct) i generalnie się to nie sprawdza, bo konfiguracji "specjalnych przypadków" jest więcej niż pożytku z tego. Moja rada: wywalić JPA, bo pożytek z tego zaden. Serio, zastanów się -> robisz klasy @Entity tylko po to żeby zaraz po wyjęciu z bazy przemapować je na obiekty domenowe albo na DTO i jak zapisujesz coś do bazy to robisz odwrotnie. Jaka jest korzyść z tych klas @Entity w takim razie? Czemu zamiast tego nie robić bardziej "biznesowego" repozytorium gdzie puszczasz query i wynik od razu mapujesz do obiektów domenowych i analogicznie w drugą stronę, zapisujesz do bazy dane generowanie bezpośrednio z obiektów domenowych? Pomijasz w ten sposób ten bezwartościowy krok mapowania.

JPA może mieć sens jak masz CRUDa i koniecznie chcesz mapować wszystko w bazie, ale wtedy to może już w ogóle encja na twarz i pchasz? ;]

1

Jeśli jednak nie zdecydujesz się na zrezygnowanie z Entity bo np. piszesz projekt na zaliczenie, lub chcesz się podporządkować standardom w istniejącym projekcie lub po prostu lubisz ból, to chyba najlepiej mapować manualnie (bo masz dużą elastyczność), a jeśli nie, to bierz pod uwagę mappery compile-time (ze wzgledu na wydajność) - np. mapstruct lub selma. Jeśli to też odpada, to najmniejszym złem będzie ModelMapper.

Tutaj masz benchmark:
https://github.com/arey/java-object-mapper-benchmark

EDIT: swoją drogą nie wiedziałem o takim wynalazku jak datus. Wygląda bardzo fajnie na pierwszy rzut oka. Czy ktoś ma jakieś doświadczenie z tym toolem?:D

1
Shalom napisał(a):

Nie robić tego wcale? ;) Widziałem w akcji kilka takich libek (jak mapstruct) i generalnie się to nie sprawdza, bo konfiguracji "specjalnych przypadków" jest więcej niż pożytku z tego. Moja rada: wywalić JPA, bo pożytek z tego zaden. Serio, zastanów się -> robisz klasy @Entity tylko po to żeby zaraz po wyjęciu z bazy przemapować je na obiekty domenowe albo na DTO i jak zapisujesz coś do bazy to robisz odwrotnie. Jaka jest korzyść z tych klas @Entity w takim razie? Czemu zamiast tego nie robić bardziej "biznesowego" repozytorium gdzie puszczasz query i wynik od razu mapujesz do obiektów domenowych i analogicznie w drugą stronę, zapisujesz do bazy dane generowanie bezpośrednio z obiektów domenowych? Pomijasz w ten sposób ten bezwartościowy krok mapowania.

JPA może mieć sens jak masz CRUDa i koniecznie chcesz mapować wszystko w bazie, ale wtedy to może już w ogóle encja na twarz i pchasz? ;]

**Kilka słów, i moja sympatia jest przy Twojej odpowiedzi. **
Inwestycja wysiłku w JPA nie zwraca mi się w satysfakcjonującym stopniu.

Zwracała mi się w (już ubitym) projekcie (desktop - więc bez konfliktów z sesjami itd), o charakterze programu jakby księgowego (więc relacyjne do bólu).
Obecnie przed oczami mam projekt webowy (więc ciągle troska, żeby sesja webowa, cache, sesja JPA, żeby nie rozszczelniać warstw itd) i więcej przeszkadza niż pomaga.

Pozytywnie mi się zwracało akurat to, co mówią "nie używać na produkcji", czyli automatyczne alterowanie tabel, dodawanie indeksów.

Alternatywę dla realizacji "biznesowego repozytorium" (podoba mi się ten zwrot, choć nie pasuje idealnie do ortodoksji) już mam, tylko zwiększyć zaangażowanie: lekki maper JDBI. ZW odróżnieniu od częściej tutaj wymienianego JOOQ-a cały jest free.

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