Mapowanie z 1 klasy na 2

Szybkie pytanie, co według Was jest lepszym rozwiązaniem:

1. tworzenie ręcznie mapperów => pełna kontrola nad kodem, brak refleksji, prosty, testowalny kod np:

   public final MapperA() {
     private MapperA() {
       throw new AssertionError();
     }
   
     public static Adto mapFromA(A a) {
       Adto result = new Adto();
       //settowanie na Adto wlasciowsci z A
       }
   }     
   

2. użycie libek typu automapper
3. pomysły ? :D

Osobiście jestem za rozwiązaniem numer 1) bo będzie chociaż gdzie debuggerem się zapiąć, ale mam wrażenie, że brakuje mi argumentów, żeby przekonać zespół...

A jakie są argumenty członków zespołu za użyciem libki? Że szybciej?

@Skoq: mniej kodu do utrzymania (xD?), szybciej, łatwiej, "przecież można dodać 4 adnotacje mapujące customowe pola których nazwy się nie pokrywają lol"

1. Ja bym się zapytał po co wam w ogóle mappery, bo zwykle dużo mapperów = jakiś fuckup w designie
2. Jeśli chodzi o mapowanie encji na DTO to moim zdaniem ręcznie to lepsza opcja. Auto-mappery fajnie wyglądają w tutorialu jak mapujesz 1:1. W prawdziwym życiu kończy się tym, że masz milion specjalnych przypadków i konfiguracja mappera jest większa niż jakbyś to zrobił normalnie.
3. Użyj tam buildera, więc nie new XYZDTO() a potem settery, tylko wszystko ustawiasz w jednym miejscu builderem.

Jeśli jakiś genialny architekt 30k wymyślił, że musi być hibernate i każde entity ma DTO mapowanego jeden do jednego to oczywiście użycie mappera jest wskazane i tu najlepszym wyborem imo jest OrikaMapper.

Natomiast nie należy dopuszczać do sytuacji, że trzeba cokolwiek mapować 1:1. W znakomitej większości mapowanych przypadków jakieś transoformacje danych jednak będą wykonywane i wtedy mappery bardziej przeszkadzają niż pomagają.

Ja bym poszedł tylko w 1. Użyłbym automappera tylko w przypadku gdyby to był szczegół implementacyjny, a nie interfejs, ale w 99% przypadkach Ci się tego nie uda zrobić, bez tak na prawdę napisania swojego automappera, ale wtedy już lepiej zrobić 1.

A argument za tym jest bardzo prosty. Jak projekt się zaczyna, to większość bibliotek które dodajesz do projektu (czyli po prostu silne dowiązania do logiki biznesowej) często pomagają i przyspieszają pracę. Ale ponieważ dodając je, nikt nie myśli o tym żeby były odseparowane, to z biegiem czasu te biblioteki zaczynają przeszkadzać coraz bardziej, aż w końcu są takim utrudnieniem które całkowicie niwelują jakiekolwiek godziny czy tygodnie jakie byś nie zaoszczędził dodając je.

W takich sytuacjach zazwyczaj dorzucam metodę w encji:

public class MyClass {
.  // kod

   public static MyClass from(final MyOtherClass object) {
      //...
   }
}

Jeśli trzeba to dorabiam oddzielny package-private mapper, gdzie trzymam kod żeby sama klasa się nie rozlazła na setki linii. W sytuacjach wyjątkowych, tj. klasę mapuje się w wielu miejscach, dorzucam builder.