N-слой POCO / DTO затруднительный

Question

Когда были только злые наборы данных и приложение Microsoft блокирует, ваши объекты передачи между слоями будут либо наборами данных / datatables, либо DTO / POCO. Я принадлежу к банде, которая любит использовать DTO / POCO.

Теперь, с этой внезапной волной картографических слоев, таких как SubSonic, Entity Framework, NHibernate и т. Д., Я все еще должен использовать свои любимые POCO? Я делаю это в основном, и при работе с веб-формами ASP.net 99% раз используют ObjectDataSource для привязки к элементам управления и функциям, характерным для каждого типа.

Должен ли я отказаться от этой любви к POCO и передать IQueryables или Entities или тому подобное и использовать другие объекты DataSource ??

Каковы плюсы и минусы использования этих объектов вместо DTO? Как это повлияет на дизайн и производительность моего приложения?

РЕДАКТИРОВАТЬ: Когда я смогу использовать другие источники данных, такие как Linq Datasorce и Entity, и т.д.?

Answer 1

Да здравствуют POCO и DTO. Они легкие, легко сериализуемые, строго типизированные, привязываемые. Никогда с ними не было проблем с производительностью, всегда делал мой код более высокого уровня чище.

Answer 2

Используйте nHibernate или другой ORM, который может отображаться в POCO :-). Затем вы можете решить передать DTO или POCO в зависимости от того, сколько разрыва вы хотите между вашим производителем и потребителем.

Вопрос, который я хотел бы задать, заключается в том, что вы собираетесь использовать данные в Entities / IQueryables и затем преобразовать их в DTO? Это очень правильный шаблон, особенно если вы собираетесь перейти границу службы и не хотите раскрывать модель своего домена; Однако есть компромисс. Минимальное снижение производительности в зависимости от размера данных, но это то, что вам нужно измерить.

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

Вот мой HQL-запрос для поиска в БД и возврата списка DTO с использованием nHibernate:

      return CurrentSession.CreateQuery(
            "select new OrganizationListDTO(o.Id,o.Name,o.xxx,o.xxx)" +
            " from Organization i where i.State=:state")
            .SetParameter("state", state)
            .List<IOrganizationListDTO>();

Суть в том, что даже если вы используете ORM, вы все равно можете использовать DTO для отчетов, подобных запросам, и позволить ему выполнять всю тяжелую работу.

Answer 3

Я тоже на перекрестке. С SOA есть и другие принципы, которые необходимо учитывать в дополнение к технологическим ограничениям - хорошо, если вы хотите оставаться на правильном пути. Я видел, как некоторые продвигают эту дискуссию на шаг вперед (включая меня самого) и задаются вопросом, как обмениваться бизнес-объектами (BO). Но я начал понимать, что это нарушает один из самых фундаментальных принципов SOA - автономность. Это неожиданно связывает ваши услуги со спецификой бизнеса. Это всего лишь сценарий, который я хотел бы привести, чтобы сравнить его с проблемой DataContract и «Entities». Я думаю, что принципы - это то, что имеет большее значение - даже за счет небольшой избыточности (т.е. выделенных DTO). Я больше склонялся к шаблону адаптера для этого, чтобы сохранить «инфраструктуру» обмена сообщениями и богатую компонентно-ориентированную модель, такую ​​как EDM, отдельно. Более того, превращение этого «шаблона адаптера» в универсального кандидата на обслуживание объектов делает его более элегантным, многократно используемым и автономным в мире SOA. Томас Эрл в своей книге «Сервис-ориентированная архитектура (концепции, технологии и дизайн)» превосходно описывает это понятие «сервисы, ориентированные на сущности». Еще одна вещь для размышления: что, если моя «сущность» не находится в одном источнике (то есть часть в базе данных и часть в текстовом файле или электронной таблице)? Приняв эти дополнительные усилия с DTO и / или полноценным сервисом, ориентированным на сущности, вы можете скрыть это и продвигать гораздо более высокую гибкость.

Линия дна: если вас не интересуют принципы SOA, и вы разрабатываете больше "ad hoc", сделайте свой выбор. Но если вы находитесь на позиции предприятия или B2B и просто не можете рисковать пресловутым «сползанием», которое SOA намеревается укротить, то вы, вероятно, будете предоставлять сервис-ориентированные сервисы SOA как первоклассные граждане и управлять ими как таковыми. Подумайте, куда идут вычисления (SOA, SaaS, PaaS и т. Д.), И какие у них общие парадигмы и принципы.

Answer 4

Я нахожу параллельные деревья объектов для домена и DTO отвратительными. Дополнительный код, который нужно сохранить, не стоит мне много, даже если я использую генераторы кода. Я думаю, что чистота слоя перепродана. Я не фанат DTO.