Czy używacie Mapstructa?

Czy używacie Mapstructra? I co o tym sądzcie?

Nofenak napisał(a):

Czy używacie Mapstructra?

Ja tak.

Nofenak napisał(a):

I co o tym sądzcie?

Pracuję z dużymi obiektami/komunikatami przychodzącymi z kolejek. Są duże bo taka była decyzja odgórna ludzi którzy to planowali.
Nie wyobrażam sobie pracy z taką ilością danych w obiektach bez szybkiego mapowania a mapstruct bardzo przyśpiesza u mnie robote. Jak coś nie działa jak chcę domyślnie, to łatwo jest te przemapowania modyfikować.
A kod generuje analogiczny do tego co i tak trzeba ręcznie zaklepać.

Mapstruct ma problemy w postaci mapowania np. przychodzących optionali na jakieś wartości nieoptionalowe - ale wtedy można customizować.

Nie, po co komplikować.

Ja nie i odradzam.

Pracowałem z tym jakiś czas temu przez chwilę w jednym projekcie (wrzucili nas tam do pomocy, decyzja od góry, że mamy tego ustrojstwa użyć) i generalnie działa się magia. Dla dużych i mocno zagnieżdżonych klas te mappery się strasznie komplikowały i były bardzo nieczytelne. Czasem ciężko było się połapać co jest czym i każdy się na czymś wykładał. Korzystaliśmy z tego w springu (componentModel = "spring" jak dobrze pamiętam) i bolączki, które gdzieś tam mi się przypominają:

• część pól mapowana domyślnie, ale bez gwarancji, że się zmapują,

• był jakiś bug z klasami zagnieżdżonymi,

• wygenerowany kod często się nie kompilował,

• wszystkie expressions i inne dynamiczne wstawki potrafiły się wyłożyć przy kompilacji, przy okazji były nieczytelne,

• podbicie wersji częściowo zmieniło działanie mapperów.

  Skutek był taki:

• po napisaniu mappera trzeba było i tak wygerować z tego kod i go linia po linii przejrzeć (a wygenerowany kod był na ogół bardzo nieczytelny i nieoptymalny, masa zbędnych if-ów i innego ustrojstwa),

• trzeba było napisać na prawdę dobre testy, żeby mieć pewność, że to działa.

Po takiej przygodzie wspólnie całym zespołem doszliśmy do wniosku, że to się nie opłaca - więcej czasu schodzi niż napisanie "ręcznie" porządnego mappera + kod jest zdecydowanie mniej pewny. Dlatego nie wspominam miło tego mapstructa i generalnie unikam jak ognia :D

Tak. Bardzo pozytywne doświadczenia. Nie wyobrażam sobie pracy bez mapstructa w projekcie.

1. Tak ogólnie to warto się zastanowić po kiego grzyba te wszystkie mapowania, bo jeśli w projekcie są głównie mapowania jeden do jednego, takich samych, albo prawie takich samych rekordów -> to co taka architektura daje?
2. Główną wadą mapstructa jest to, że ułatwia te mapowania, przez co trudniej się zorientować, że mamy jakąś patologiczną architekturę z tonami nonsensownych mapowań.
3. Mapstruct jest dużym problemem w legacy code i refaktoringu -> nie widać kto i kiedy modyfikuje dane pole, dramat przy szukaniu błędów. Przy zmianach, dodawaniu pól itp. nie ma żadnych błędów kompilacji, dopiero na produkcji lecą nulle, bo zapomnieliśmy pole dodać w kilku jeszcze miejscach.
4. Jest możliwe, że gdzieś kombinacja frameworków itp. powoduje, że musimy i warto robić mapowania, wtedy mapstruct może się przydać -> ale IMO w większości przypadków jeśli widać, że mapstruct się przydaje, to mamy jakąś przeinżynierowaną architekturę.

Nie lubię mapstructa (ani Dozera, ani Oriki). Wyobrażam sobie projekt, przy którym tego typu rzeczy dają realne korzyści inne niż "do każdej klasy muszę dopisać ręcznie mapper", ale o ile kiedyś próbowałem tego typu rzeczy automatyzować, o tyle teraz wydaje mi się to antyproduktywne (tj. oszczędzamy teraz trochę czasu by za kilka miesięcy dołożyć sobie roboty).

Fajnie by było gdyby dało się ten kod źródłowy generować do .java za pomocą jakiegoś pluginu mavenowego - wtedy takie narzędzie mogłoby być przydatne. Niestety, kod jest generowany w trakcie kompilacji, co utrudnia debugowanie czy po prostu prześledzenie co się dzieje pod spodem.

tak ale nie z wlasnego wyboru...

Korzyści nie było w stosunku do tradycyjnego mappera. Ani szybciej, ani lepiej, ani czytelniej. No i w compile time, co dla mnie osobiście jest minusem.

+1 dla @Majksu zwłaszcza, że żyjemy w czasach gdzie nawet testy jednostkowe możemy sobie dosyć dobrze wygenerować na podstawie samego tytułu testu i na podstawie kilku innych w klasie testowej.
Napisanie "ręcznie" takiego mappera z wykorzystaniem np. github copilot'a to pewnie kilka sekund roboty (a i pewnie unit testy wygeneruje dodatkowo bez problemów).

Naturalnie można też ręcznie jeżeli jest taka potrzeba.

Nie używam. Nie miałem nigdy potrzeby.

Korzystałem ale miałem przypadki kiedy i tak ręcznie trzeba było coś konwertować przy przemapowaniu na inny obiekt (więc tracił sens) i przy lokalnym developmencie często nie odświeżało wygenerowanego kodu i kończyło się tym, że przed każdym restartem apki kasowałem wygenerowany kod żeby mieć 100% pewności, że wszystkie pola się zmapują bo potrafiłem zmarnować kilkanaście minut na szukanie powodu błędu