Spring, problem z Mapowaniem jednego z pól za pomocą mabstruct.

Cześć, mam pewien problem. Otóż próbuję zrobić kampanie reklamową z polem "słowa kluczowe" w relacji wiele do wielu, gdzie w DAO typem jest lista Keyword a w DTO lista Stringów. Gdy próbuję wygenerować mapowanie za pomocą mabstructa wyskakuje mi błąd który jak rozumiem zakłada implementacje kolejnej metody, tylko szczerze mówiąc kompletnie nie wiem jak się za to zabrać bo wcześniej nie miałem tego typu problemów a w internecie treści są dość ubogie lub niezrozumiałe, albo po prostu nie potrafię szukać.
Poniżej screen z błędem.

podrzucam też githuba z kodem dla szerszego kontekstu
https://github.com/Miedzic/campaign

Podpowiedź mówi co masz zrobić. Masz napisać metodę która przyjmuje Liste KeyWordów a zwraca Liste Stringów.
Przelatujesz po kolekcji streamem, i mapujesz KeyWord na string czyms w stylu

keyWords .stream() .map(kw -> kw.getName()) .collect(Collectors.toList());

@kixe52: Tak ale wtedy musiałbym zrobić ręcznie CampaignMapperImpl, a ja używam mappera który to robi automatycznie mapstructem i nie wiem jak zrobić taką metodę i czy na przykład mogę zamienić interfejs na klasę abstrakcyjna, problemem nie jest sama implementacja.

stwórz implementację tego interfejsu i ręcznie naklep mapowanie. Tak w ogóle to dobrze radzę wywal tego mapstructa i zrób wszystko ręcznie. Więcej kontroli, mniej problemów

No dobra to spróbuje ręcznie i tyle. Szkoda.

Zanim zaczniesz klepać to ręcznie możesz spróbować z ModelMapperem (http://modelmapper.org/)

Przecież w opisie błędu masz info, co musisz dodać.

Jak zwykle top3 Googla rozwiązuje problem: https://www.baeldung.com/java-mapstruct-mapping-collections

W rzeczywistym komercyjnym świecie nie robi sie zbytnio takich mapperów, bo za mapowaniami zazwyczaj jakaś logika. Takie mappery mają sens co najwyżej wtedy kiedy Twój backend to zwykła nakładka na bazę danych a frontend to GUI to tej bazy danych ;]

scibi_92 napisał(a):

W rzeczywistym komercyjnym świecie nie robi sie zbytnio takich mapperów, bo za mapowaniami zazwyczaj jakaś logika. Takie mappery mają sens co najwyżej wtedy kiedy Twój backend to zwykła nakładka na bazę danych a frontend to GUI to tej bazy danych ;]

W porządku, dzięki za dobrą radę. Ostatecznie zrobiłem taki mapper z tą "jakąś" logiką i jak się już umie to nie widzę specjalnej różnicy poza tym że jest szybsze i wygodniejsze ale może mnie jeszcze życie wyprowadzi z błędu.

nie widzę specjalnej różnicy

Takie auto-mapery działają dobrze na przykładach z tutoriala gdzie mapujesz sobie 1:1, nazwy pasują i w ogóle wszystko się spina. W praktyce z taką sytuacja rzadko się spotkasz i z mojego doświadczenia często czytelniej jest napisać sobie coś "ręcznie" niż bawić się w magiczne konfiguracje mapstructa czy innego toola do mapowania. Dodatkowo ja osobiście nie lubie kiedy za dużo rzeczy w kodzie, bez uzasadnionej przyczyny, dzieje sie za pomocą jakiejś magii i nie ma nawet gdzie postawić breakpointa jak sie zacznie sypać.

To zrozumiałe że każdy ma swoje preferencje, najpewniej masz sporo racji, ale chyba nie powinno to oznaczać że od razu należy tą "magie" demonizować. No ale tak czy inaczej dzięki za odpowiedzi

Miedzic napisał(a):

To zrozumiałe że każdy ma swoje preferencje, najpewniej masz sporo racji, ale chyba nie powinno to oznaczać że od razu należy tą "magie" demonizować. No ale tak czy inaczej dzięki za odpowiedzi

"magię" zazwyczaj używa się by przyspieszyć development np. taki Spring ale jest to kosztem mniejszej kontroli nad kodem. Modelmappery itd. zazwyczaj nie przyspieszają bo jak nie masz mapowania do tych samych typów to i tak musisz to recznie naklepać, a w reszcie przypadków pozbywasz sie mozliwosci postawienia breakpointa. Trust me - o wiele szybciej napisać ręcznie jakąś metodę mapującą z builderem. Aczkolwiek jest mi znane Twoje podejście do tematu, miałem identycznie zaczynając swoją przygodę w IT :)

No tak jak mówię, życie mnie zweryfikuje. Natomiast takie szybkie mapowanie nauczył mnie znajomy senior który nie używanie go nazwał jakoś tak "no jak ktoś lubi marnować czas to spoko" więc ten upór z mojej strony nie polega na tym "ego początkującego" który sugerujesz, bardziej konflikt autorytetów znajomy/internet

Takie mappery to bardzo często gigantyczne marnotrawstwo czasu.

• tracimy czas na refaktoringu: wydaje się, że pola nikt nie używa, więc kasujemy :-) a jest ono kopiowane refleksją, o czym przekonujemy się dopiero w testach (w najlepszym razie), a czasem na produkcji
• jak chcemy poanalizować kod z mapperami to zamiast prostej nawigacji i szukania po call hierarchy musimy jechać searchem tekstowym, nie jest to wielki dramat, ale męczy czasem
• najgorzej jak mamy mappery działające na reflekcji, ale ze skomplikowaną (custom) logiką - wtedy nie dość, że nie działa wyszukiwanie po użyciu, to jeszcze search tekstowy zawodzi.

Tak, że te kilkanaście minut zaoszczędzone na starcie jest potem wielokrotnie zwracane przy refaktoringach, zmianach, i jak przychodzą nowi członkowie zespołu.
Oczywiście : depends. Jak masz projekt z DTOsami na dziesiątki pól to ręczne mappery bywają jeszcze gorsze od tych automatycznych (błędogenne).

W danym projekcie najgorsze są nie mappery, ale ten nieszczęsny @NoArgsConstructor, który w połączeniu z mapperami (ręcznymi czy automatycznymi) gwarantuje dużo fajnych null pointerów.

Przy 1..5 polach można śmiało korzystać z MapStruct.
Przy 6..50 polach piszesz własne mappery.
Natomiast gdzieś powyżej tej liczby (u mnie to było ok. 3 tys pól) opłaca się zrobić własnego DSLa do mapowania.