Должны ли POCO быть производными от DTO или лучше этого не делать?
-
13-09-2019 - |
Вопрос
При создании n-уровневого решения я не хочу раскрывать свои бизнес-объекты, но использую DTO вместо этого.С другой стороны, я не хочу дважды определять объекты и все время писать копирующий код.
Теперь моя идея состояла бы в том, чтобы написать DTO, которые содержат все необходимые поля и свойства, но без логики (только состояние).
Затем я бы извлекал свои бизнес-объекты из этих DTO, расширяя их своей бизнес-логикой, работая со свойствами базовых классов DTO.Эти объекты также будут объектами, сохраненными в используемом ORM (NHibernate).
При таком подходе на стороне сервера я мог бы работать с бизнес-объектами и передавать их непосредственно клиенту (они являются производными, поэтому их можно изменять).Я бы не был вынужден таким образом раскрывать свою бизнес-логику и экономить много кода.
Считаете ли вы такой подход разумным?
С уважением,
Себастьян
Решение
Возможно, вы захотите рассмотреть следующее:
"..., потому что сохранение DTO в неведении об объектах домена позволяет повторно использовать DTO в разных контекстах. Аналогично, вы не хотите, чтобы объекты домена знали о DTO, потому что это может означать, что изменение ДТО потребует изменения кода в логика домена , что привело бы к кошмару обслуживания.
Лучшим решением является использование Шаблон ассемблера, который создает DTO из бизнес-объектов и наоборот.Ассемблер - это специализированный экземпляр Картограф шаблон, также упомянутый в Шаблоны архитектуры корпоративных приложений...."
От Образец и практика:Объект передачи данных
Кроме того, я не пользовался им сам, но вы, возможно, захотите проверить Автоматический преобразователь также хорошо.
Другие советы
Мне кажется разумным.В Linq to SQL бизнес-объекты получаются из DTO с помощью частичных классов.
«Тогда я бы получил свои бизнес-объекты из этих DTO». Имейте в виду, что DTO могут выглядеть иначе, чем BO, они могут содержать свойства из 2 или 3 BO.