[Patres]

#java #programowanie
Programuję już jakiś czas i tafiałem do projektów z różnymi frameworkami do mapowania i zaczynam się zastanawiać po co? Mapowanie klas wydaje się być czymś super prostym: zbiór getterów i setterów. Naprawdę potrzebujemy do tego frameworka? Ktoś potrafi mi dać jakiś sensowny argument za frameworkiem?
1. Nie musmy definiować wszystkich pół gdy nazwa jest taka sama - OK, ale jak zrobimy refactoring i zmieni nam się nazwa pola/gettera to mapper przestanie działać. Chyba lepiej mieć nad tym kontrolę?
2. Definiujemy tylko pole jakie mają się mapować i reszte zrobi framework - To co wyżej. Zmienimy nazwę pola (Stringa) to IDE nam nie podmnieni tych Stringów "name" -> "firstName"

[Saly]

@Patres: IMO takie frameworki kuszą, bo na początku są bardzo sensowne: często mapowane modele są sobie równe, bo są projektowane pod jeden use case. Dopiero potem wraz z ewolucja dochodzą różnice i okazuje się, że utrzymanie i ogarnianie biblioteki do mapowania to większy cyrk, niż żmudne i ręczne mapowanie

[aloucie]

@Patres:
Po prostu trzeba myśleć co się robi i mieć testy
¯\_(ツ)_/¯
Czym się różni sytuacja gdzie zapomnisz zmienić mapping, od zapomnienia wywołania settera?
Jeśli nie wyj***e ci się żaden unit kiedy pole w modelu przestało być ustawiane, to gratuluję wiary w swój codebase.

[globalbus]

@Patres: No właśnie jak masz MapStruct, to on przy dobrym skonfigurowaniu wywali się, jeśli zapomnisz zmapować pola. Trzeba będzie ręcznie dokonfigurować lub dopisać ignore.
Mapper, który jest napisany ręcznie tego nie zrobi.

[Patres]

@aloucie w tym przypadku niczym, ale jak zmienię nazwę pola to framework nie ogarnie że pole "name" to teraz "firstName" a gdyby było to pole to IDE by mi to podmieniło na getFirstName(), więc dalej nie widzę korzyściach

[Patres]

@globalbus Racja, pierwszy argument który ma dla mnie sens. Dzięki! (Choć dalej nie przekonuje mnie to czy ta zaletą przewyższa wady)

[globalbus]

@Patres: jak masz w ciul mapperów, to wtedy ma sens. Do cruda z 3-4 dto'sami to jest armata na wróble.
Kiedyś były frameworki mapujące czasu wykonania, typu Orika. To generalnie było słabe. Obecne wynalazki działają w czasie kompilacji i wydajnościowo niczym się to nie różni od ręcznie pisanej litanii setterów.

Mapstruct ma plugin do intellij, podpowiada dość dobrze. Jedyne wywałki, to jak stosujesz zapis target = "entityA.entityB.fieldC", bo wtedy nie będzie

[retardo]

@Patres: są frameworki które firstName pomapuje na name jeśli typy się zgadzają i nie ma czegoś innego w stylu secondName. IMO taka oszczędność czasu + mniej do utrzymania przewyższa tę jedną wadę, że jakieś pole od czasu do czasu trzeba dopisać ręcznie. W ręcznym utrzymywaniu możesz popełnić błąd jak masz źle testy napisane. W przypadku mapperów dostajesz błąd na etapie kompilacji/startu.