Должны ли POCO быть производными от DTO или лучше этого не делать?

Question

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

Теперь моя идея состояла бы в том, чтобы написать DTO, которые содержат все необходимые поля и свойства, но без логики (только состояние).

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

При таком подходе на стороне сервера я мог бы работать с бизнес-объектами и передавать их непосредственно клиенту (они являются производными, поэтому их можно изменять).Я бы не был вынужден таким образом раскрывать свою бизнес-логику и экономить много кода.

Считаете ли вы такой подход разумным?

С уважением,

Себастьян

Answer 1

Возможно, вы захотите рассмотреть следующее:

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

Лучшим решением является использование Шаблон ассемблера, который создает DTO из бизнес-объектов и наоборот.Ассемблер - это специализированный экземпляр Картограф шаблон, также упомянутый в Шаблоны архитектуры корпоративных приложений...."

От Образец и практика:Объект передачи данных

Кроме того, я не пользовался им сам, но вы, возможно, захотите проверить Автоматический преобразователь также хорошо.

Answer 2

Мне кажется разумным.В Linq to SQL бизнес-объекты получаются из DTO с помощью частичных классов.

Answer 3

«Тогда я бы получил свои бизнес-объекты из этих DTO». Имейте в виду, что DTO могут выглядеть иначе, чем BO, они могут содержать свойства из 2 или 3 BO.