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

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

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

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

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

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

С уважением,

Себастьян


architecture c# dto n-tier-architecture poco
person Sebastian P.R. Gingter    schedule 03.11.2009    source источник
comment
Как вы собираетесь выполнять аппроксимацию вашего бизнес-объекта без копирования-копирования, когда вы получаете DTO от клиента?   -  person Chansik Im    schedule 03.11.2009

Ответы (3)


arrow_upward
6
arrow_downward

Вы можете рассмотреть следующее:

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

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

из Шаблон и практика: объект передачи данных

Кроме того, я не использовал его сам, но вы также можете проверить AutoMapper.

person Chansik Im    schedule 03.11.2009
comment
+1 для изменения DTO потребуется изменить код в логике домена. - person Abram Simon; 03.11.2009

arrow_upward
1
arrow_downward

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

person Robert Harvey    schedule 03.11.2009

arrow_upward
0
arrow_downward

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

person Mirza    schedule 04.03.2012