Как бороться с большим количеством DTO?

Question

[MakarMS]

Привет всем. У меня есть класс репозитория с методом, который возвращает ассоциативный массив. Однако я бы хотел работать с объектом.

Сейчас я пытаюсь решить, как это реализовать.

• Первый вариант - получать дополнительные данные при каждом запросе, чтобы создать полноценный объект сущности, даже если мне нужно всего несколько полей.
  
• Второй вариант - создавать DTO-объекты, содержащие только два необходимых поля.
  

В первом случае возникают накладные расходы из-за дополнительных запросов. Во втором случае возникает избыток классов DTO.

Какой подход здесь лучше? Может быть, мне создать объект DTO с необязательными полями? Но в таком случае это приведет к двусмысленности - вам придется помнить, какие поля заполнены, а какие нет.

Какова лучшая практика для такого сценария?

Comments

[Adamos]

Выглядит как остановка в одном шаге от DTO-классов - наследников одного абстрактного с двумя обязательными полями.

[MakarMS]

Adamos, давит то, что таких DTO будет много десятков в большом проекте. Хотелось бы узнать бест практики на этот счёт.

[Adamos]

MakarMS, бест практика насчет классов - это иметь их там, где они нужны.
Лучше ворох чистых DTO, никому не мешаюших в своей папке и своем неймспейсе, чем простыни проверок ключей и значений массивов по всему рабочему коду.

[Kentavr16]

Насколько я понял суть вопроса - можно попробовать через билдер, но это нужно смотреть на месте

[tukreb]

Лучше много DTO, чем гадать, где какой ключ.
А когда создадите миллион DTO, увидите паттерн и сможете решить где заменить на наследование, а где на что-то другое.

[Дмитрий]

Виртуальное dto

Answer 1

[Василий Банников]

Во втором случае возникает избыток классов DTO.

А минусы будут? (С)