Нормально ли делать методы в DTO-классах?

Question

[Владимир Варнавский]

Нормально ли делать статическую фабрику в DTO-классе? Или конструктор с параметрами?

Мой частный случай такой: получаю JSON из внешней системы и хочу на основании JSONа создать внутренний DTO-объект. Очень тянет впихнуть логику парсинга прямо в DTO (конструктор или статический метод), но не уверен, что это архитектурно правильно. Тут же можно было бы обработать неправильность JSONa и сделать какие-то простые маппинги. Есть какие-то мудрые рекомендации на этот счёт?

Answer 1

[Максим Федоров]

Неправильно, валидаторы и десериализаторы пусть будут в конверторах, например для контроллеров
Сами ДТО просто плоские глупые объекты. разве что маппинг и констрейнты повесить на поля (насколько это позволяет язык), а-ля через аннотации в PHP/Java

У меня так ДТО выглядит для JSON (язык PHP)

Использование:


Если фреймворк/язык не позволяет это делать снаружи от контроллера, то можно внутри сделать похожий маппинг, передав ответственность похожей абстракции для конвертации