Разные ДТО для создания/получения объектов VS один ДТО, но запретить сериализацию null?
Только учусь, делаю первые программы и у меня выходит несколько дто классов для создания и получения объектов ( для создания нужно явно меньше информации ).
Я подумал, что можно немного сделать по-другому:
Один ДТО, в нем создать отдельный конструктор для создания объектов. Уникальные филды, которые используются только при создании не инициализировать при получении объекта. А в настройках сериализации запретить сериализацию null-объектов. Но будет ли это хорошей практикой? Или это будет позорный костыль, который стыдно будет кому-то отправить?
Я очень ценю Ваши ответы! И задаю вопрос только потому, что слаб в good/bad practices
P.S. влияет ли передача объекта с некоторыми лишними null полями на оптимизацию?
сегодня твоя сущность отличается одним полем, а завтра 10, 20, 30. И все, весь код теперь рефакторить с заменой где это использовалось, хотя изменение не должно было коснуться другой фичи
Добрый день.
Как по мне лучше создавать отдельный DTO на каждую нужду вместо того, чтобы скомпоновать все в один.
Например, UserCreationDTO, UserRequestDTO, UserResponseDTO и т.д.
Skoleev, вам коллега Дмитрий Свиридов правильно подсказал. DTO могут быть для разных целей и их нужно разделять, но можно же иметь некий базовык класс, чтобы не копировать каждый раз и добавлять доп. поля
Простой
