POCO vs DTO:Можно ли частично увлажнять доменный объект?
-
05-07-2019 - |
Вопрос
Часто требуется, чтобы объект домена отображался различными способами в пользовательском интерфейсе;списки, результаты поиска, просмотр и редактирование страниц, а также в верхних и нижних колонтитулах и всплывающих окнах.Обычно у вас есть несколько разных "представлений" объекта домена, в каждом из которых отображаются разные поля.
Большинство советов, по-видимому, заключаются в использовании DTO для получения данных, когда вам требуется подмножество или надмножество.Обслуживание DTO сопряжено с большими накладными расходами.Это плохой подход - просто заполнять свойства объекта домена, необходимые для каждого сценария.Например, вы могли бы использовать профиль, чтобы указать, какие свойства должны быть включены, например:
Обслуживание.GetDomainObjects(int ListID, Profile.Список профилей);Обслуживание.GetDomainObjects(строка searchParam, Profile.SearchProfile);
Решение
Для меня это сводится к тому, что вы хотите, чтобы накладные расходы были, либо у вас будет набор разных классов для представления ваших DTO, либо у вас будет набор методов, каждый из которых возвращает один и тот же объект домена, но с разными "гидратированными" полями.
Вот пара вопросов, которые я бы задал, чтобы помочь принять решение::
- каковы накладные расходы на увлажнение всего объекта?Действительно ли дополнительная сложность (DTO или частично гидратированные объекты) того стоит?
- кто-нибудь еще собирается использовать ваш код?Вы не должны путать людей с частично гидратированными объектами, DTO могут быть более понятными, когда люди придут поддерживать ваш код.
У меня есть небольшое личное предпочтение DTO, поскольку я чувствую, что долгосрочное обслуживание вашей системы будет проще.Если у вас группа для одного человека или это одноразовое приложение, я могу полностью понять нежелание вводить кучу дополнительных классов, которые будут загромождать ваш код.