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"
  • Najlepsze
  • Wszystkie komentarze
Saly
Saly
7
@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
a.....e
a.....e
@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
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.
globalbus
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
Patres
Patres Autor
0
@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
Patres Autor
0
@globalbus Racja, pierwszy argument który ma dla mnie sens. Dzięki! (Choć dalej nie przekonuje mnie to czy ta zaletą przewyższa wady)
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.