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.