Zysk z konstruktora jest taki, że jak mamy tam 2 parametry i dojdzie 3ci - to nie zapomnimy ustawić. Bo się nie skompiluje. A setter zawsze zawodny jest.
Jest tak zawodny jak dobre i sensowne mamy pokrycie testami.
Problem z DTO to nie jest problem "mamy 2 parametry i dochodzi trzeci", tylko "jest 17 parametrów i dochodzi 6".
Dodatkowo nie wiem o co chodzi z tym dodatkowym kodem - akurat bardzo prostacka niemutowalna klasa to nawet mniej kodu niż mutowalna. W javie ani setterów, ani getterow nie robię. Tylko konstruktor i pola final. Na DTO starcza. (Do ciekawszego fp nie starczy, ale tu nie o tym mowa).
No, a C# nie jest taki magiczny jak Java, i nie ma ujemnych linii kodu. Napisanie konstruktora, to jednak więcej kodu niż brak konstruktora.
I taki konstruktor do DTO/VM, to po prostu taki sztuczny twór (co sugeruje płacenie od linijki), który będzie się często zmieniał i irytował, a nie da żadnej wartości dodanej. DTO/VM to "obiekcik" (bo obiekt to to nie jest, przynajmniej nie według definicji OOP), który żyje w aplikacji bardzo krótką chwilę, jest tworzony w jednym miejscu, a następnie przesyłany przez jakieś medium. Nie ma nawet okazji go skutecznie zmutować.
No chyba, że ktoś ma architekturę DTO na twarz i pchasz, bierze np. taki token zwrócony przez PayPala i przepuszcza go przez 40 klas w swoim systemie, żeby go obudować w dane zamówienia, płatności, klienta, itd. No, ale przy takim podejściu, to konstruktor też nie pomoże. Nic już nie pomoże.
Tak naprawdę, to cały problem wynika głównie z tego, że języki, którym posługuje się znaczna część branży są upośledzone i mają jedno słowo class
, którego trzeba używać do definiowania skrajnie różnych rzeczy: algorytmów, orkiestratorów, krotek, rekordów, itd.