Разные ДТО для создания/получения объектов VS один ДТО, но запретить сериализацию null?

Question

[Skoleev]

Только учусь, делаю первые программы и у меня выходит несколько дто классов для создания и получения объектов ( для создания нужно явно меньше информации ).
Я подумал, что можно немного сделать по-другому:
Один ДТО, в нем создать отдельный конструктор для создания объектов. Уникальные филды, которые используются только при создании не инициализировать при получении объекта. А в настройках сериализации запретить сериализацию null-объектов. Но будет ли это хорошей практикой? Или это будет позорный костыль, который стыдно будет кому-то отправить?

Я очень ценю Ваши ответы! И задаю вопрос только потому, что слаб в good/bad practices

P.S. влияет ли передача объекта с некоторыми лишними null полями на оптимизацию?

Comments

[Jacen11]

сегодня твоя сущность отличается одним полем, а завтра 10, 20, 30. И все, весь код теперь рефакторить с заменой где это использовалось, хотя изменение не должно было коснуться другой фичи

Answer 1

[Орхан Гасанлы]

Добрый день.
Как по мне лучше создавать отдельный DTO на каждую нужду вместо того, чтобы скомпоновать все в один.
Например, UserCreationDTO, UserRequestDTO, UserResponseDTO и т.д.

Comments

[Skoleev]

Очень хочу уточнить, выходит, будет хорошей практикой создавать отдельный ДТО даже если 1 филд лишний? Или если 1, то можно проигнорировать?

[Дмитрий Свиридов]

Skoleev, можно ж отнаследоваться от нужного DTO и добавить недостающее поле.

[Орхан Гасанлы]

Skoleev, вам коллега Дмитрий Свиридов правильно подсказал. DTO могут быть для разных целей и их нужно разделять, но можно же иметь некий базовык класс, чтобы не копировать каждый раз и добавлять доп. поля