Если свойства в объекте передачи данных расширяют внешние ключи или просто раскрывают их первичные ключи

Question

У меня есть EmployeeDTO, который представляет запись о сотруднике в базе данных.Таблица «Сотрудник» имеет отношение к отделу, а отношение «один ко многим» - к разрешению.

В моих сущностях они представлены в виде полностью развернутого свойства Department и списка полностью развернутых объектов разрешений.

Вопрос в том, должен ли DTO иметь полностью развернутое свойство DepartmentDTO для DepartmentId?Должен ли DTO иметь список полностью развернутых свойств PermissionDTO List of PermissionId?

Answer 1

Как и все в дизайне, это зависит от ваших потребностей.

• Если вам нужно часто видеть и привязать к дочерним свойствам, и вы хотите сделать это как можно проще для разработчиков для использования ваших DTO, вы можете хотите, чтобы явные фабричные методы давали вы полностью развернули дочерние свойства.
• Если вам нужна простота кода, не расширить свойства внешнего ключа и просто позвольте разработчикам получить ребенка объект / коллекции, которые они хотят по ключу по мере необходимости.

Вы можете столкнуться с проблемами при рекурсии; вы также расширяете все свойства внешнего ключа объекта Department? Что делать, если есть ссылка на другой EmployeeDTO в подклассе Department?

Microsoft Entity Framework, а также другие популярные платформы бизнес-объектов обрабатывают эту концепцию с помощью отложенной загрузки - извлекать полностью развернутое дочернее свойство только в том случае, если это требуется кодом. Это, вероятно, наиболее гибкое решение, но оно имеет небольшие накладные расходы / задержку, поскольку дочерние свойства не могут быть получены в том же вызове базы данных, что и родительский объект. Конечно, это не только DTO.

Answer 2

Да и Нет. Это зависит от вызова и от того, нужны ли вам все дополнительные свойства при каждом вызове.Это также может зависеть от используемой вами технологии ORM, которая может реализовывать отложенную загрузку и может повлиять на ваше решение (если вы передаете прямые объекты сущностей, хотя это не рекомендуется ).

Обычно создается один случайный DTO, содержащий все необходимые свойства, и один или несколько объектов DTO, которые предоставляют больше функциональных возможностей и используются другими методами.Например, у меня есть класс BasicUser, который содержит только UserName и DisplayName, и у меня есть User, который содержит больше, включая Permissions, и наследуется от `BasicUser.