POCO vs DTO:Можно ли частично увлажнять доменный объект?

Question

Часто требуется, чтобы объект домена отображался различными способами в пользовательском интерфейсе;списки, результаты поиска, просмотр и редактирование страниц, а также в верхних и нижних колонтитулах и всплывающих окнах.Обычно у вас есть несколько разных "представлений" объекта домена, в каждом из которых отображаются разные поля.

Большинство советов, по-видимому, заключаются в использовании DTO для получения данных, когда вам требуется подмножество или надмножество.Обслуживание DTO сопряжено с большими накладными расходами.Это плохой подход - просто заполнять свойства объекта домена, необходимые для каждого сценария.Например, вы могли бы использовать профиль, чтобы указать, какие свойства должны быть включены, например:

Обслуживание.GetDomainObjects(int ListID, Profile.Список профилей);Обслуживание.GetDomainObjects(строка searchParam, Profile.SearchProfile);

Answer 1

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

Вот пара вопросов, которые я бы задал, чтобы помочь принять решение::

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

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