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

Question

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

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

service.GetDomainObjects (int listID, Profile.ListProfile); service.GetDomainObjects (строка searchParam, Profile.SearchProfile);

Answer 1

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

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

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

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