Как написать объект передачи данных?

Question

В моей архитектуре N-уровня у меня есть DTO (AddressResponseDTO), где у меня есть около 20 свойств. Когда запрос уровня представления (AddressRequestContext) отвечает за конкретную операцию поиска на мой бизнес-уровень, я отправлю этот DTO (AddressResponseDTO) в PL.

Но это не всегда так. Запрос на поиск адреса будет изменен. Иногда мне нужно отправить только 3 свойства (скажем, город, почтовый индекс и количество адресов), а иногда это может быть 5. Так что я могу по-прежнему иметь один и тот же DTO с 20 функциями для повторного использования всех видов поиска запрос.

Answer 1

В ОП говорится, что иногда используется только 3 из свойств, может быть несколько решений:

• Создать DTO со всеми свойствами, и specifiy специальных значений, чтобы показать, какие свойства не являются (например, использовать значения nullables или специальные значения). Это требует большого количества проверок в коде.

• Создайте DTO с 3 свойствами. Наследуйте второй DTO от этого и добавьте все остальные свойства. Ваши методы могут получить базовый класс в качестве параметра и проверить, получен ли базовый или производный класс. Простая проверка, например if (myDto is DtoBase) ..., быстро покажет, какие свойства были отправлены с DTO. (Это будет работать только для увеличения числа свойств, в иерархии наследственных DTOS)

• Если есть более чем одна возможная группировка свойств, представляющих интерес, вы можете использовать класс DTO для каждой группы и:

  • создать класс, который имеет этот DTO в качестве членов. Если они вам не нужны, оставьте их пустыми. Таким образом, вы можете проверить каждую группу простым if (containerDto.Dto1 != null)
  • определите столько параметров DTO, сколько необходимо для каждого случая.

Я не люблю «особое значение» путь, потому что она требует больше коды и больше ошибок. Кроме того, он заставляет вас (де) сериализовать больше информации, чем необходимо во многих случаях.

Answer 2

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

Или вы можете создать несколько определений класса DTO для разных вариантов использования. В этом случае я предлагаю использовать некоторую иерархию классов между этими классами.

Я думаю, что это зависит от вас и от сложности вариантов использования, которые вы предпочитаете использовать.

Answer 3

Нет никакого вреда при написании DTO с 20 объектами.

Однако, если свойства могут быть сгруппированы вместе, лучше группировать связанные свойства в объект, например, вы можете группировать Город, Почтовый индекс в адрес.