Простой старый объект CLR против объекта передачи данных

Question

POCO = Простой старый объект CLR (или лучше: класс)

DTO = Объект передачи данных

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

POCO и DTO - это одно и то же?

Answer 1

POCO следует правилам ООП. Он должен (но не обязан) иметь состояние и . POCO происходит от POJO, придуманного Мартином Фаулером [ анекдот здесь ]. Он использовал термин POJO как способ сделать его более сексуальным, чтобы отвергнуть тяжелые реализации EJB. POCO следует использовать в том же контексте в .Net. Не позволяйте фреймворкам определять дизайн вашего объекта.

Единственной целью DTO является передача состояния, и оно не должно иметь никакого поведения. См. объяснение DTO Мартина Фаулера для примера использования этого шаблона.

Вот в чем разница: POCO описывает подход к программированию (старомодное объектно-ориентированное программирование), где DTO - это шаблон , который используется для «передачи данных» с использованием объектов.

Хотя вы можете рассматривать POCO как DTO, вы рискуете создать модель анемичного домена , если вы это сделаете. Кроме того, существует несоответствие в структуре, поскольку DTO должны быть предназначены для передачи данных, а не для представления истинной структуры бизнес-сферы. Результатом этого является то, что DTO имеют тенденцию быть более плоскими, чем ваш фактический домен.

В домене любой разумной сложности вам почти всегда лучше создавать отдельные доменные POCO и переводить их в DTO. DDD (доменный дизайн) определяет антикоррупционный слой (еще одна ссылка здесь , но лучше всего купить книгу ), что является хорошим структура, которая делает сегрегацию четкой.

Answer 2

Мне, вероятно, излишне вносить свой вклад, поскольку я уже изложил свою позицию в своей статье в блоге, но последний абзац этой статьи подводит итог:

Итак, в заключение, научитесь любить POCO и убедитесь, что вы не распространяете никакой дезинформации о том, что это то же самое, что DTO. DTO - это простые контейнеры данных, используемые для перемещения данных между уровнями приложения. POCO - это полноценные бизнес-объекты с одним требованием, чтобы они оставались невосприимчивыми к постоянству (нет методов get или save). И наконец, если вы еще не проверили книгу Джимми Нильссона, возьмите ее в местном университете. У него есть примеры на C #, и он отлично читается.

Кстати, Патрик. Я прочитал POCO как статью о стиле жизни, и я полностью согласен, что это фантастическая статья. На самом деле это раздел из книги Джимми Нильссона, который я рекомендовал. Я понятия не имел, что это было доступно онлайн. Его книга действительно является лучшим источником информации, которую я нашел в POCO / DTO / Repository / и других методах разработки DDD.

Answer 3

POCO - это просто объект, который не зависит от внешней среды. Это просто.

Неважно, имеет ли POCO поведение или нет.

DTO может быть POCO, как и объект домена (который, как правило, имеет богатое поведение).

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

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

Answer 4

Я написал статью для этой темы: DTO против объекта-значения против POCO .

Короче говоря:

• DTO! = Значение объекта
• DTO ⊂ POCO
• Объект значения ⊂ POCO

Answer 5

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

Один из примеров, когда POCO отличается от DTO, - это когда вы говорите о POCO внутри модели вашего домена / модели бизнес-логики, которая является хорошим представлением OO вашего проблемного домена. Вы можете использовать POCO во всем приложении, но это может привести к нежелательным побочным эффектам, таким как утечка знаний. DTO, например, используются на сервисном уровне, с которым взаимодействует пользовательский интерфейс, DTO представляют собой плоское представление данных и используются только для предоставления пользовательскому интерфейсу данных и передачи изменений обратно на сервисный уровень. Уровень обслуживания отвечает за сопоставление обоих направлений DTO с объектами домена POCO.

Обновление Мартин Фаулер сказал , что такой подход - трудный путь, и его следует применять только в случае существенного несоответствия между уровнем домена и пользовательским интерфейсом.

Answer 6

вот общее правило: DTO == зло и индикатор чрезмерно спроектированного программного обеспечения. ПОКО == хорошо. «корпоративные» шаблоны разрушили мозги многих людей в мире Java EE. пожалуйста, не повторяйте ошибку в .NET land.

Answer 7

Основной вариант использования DTO - возврат данных из веб-службы. В этом случае POCO и DTO эквивалентны. Любое поведение в POCO будет удалено при его возврате из веб-службы, поэтому не имеет значения, имеет ли оно поведение.

Answer 8

Классы DTO используются для сериализации / десериализации данных из разных источников. Если вы хотите десериализовать объект из источника, не имеет значения, какой это внешний источник: сервис, файл, база данных и т. Д., Возможно, вы захотите использовать только некоторую его часть, но вам нужен простой способ десериализации этих данных в объект. после этого вы копируете эти данные в модель XModel, которую хотите использовать. Сериализатор - это красивая технология для загрузки объектов DTO. Зачем? вам нужна только одна функция для загрузки (десериализации) объекта.

Answer 9

Даже не называйте их DTO. Они называются Модели .... Период. Модели никогда не имеют поведения. Я не знаю, кто придумал этот тупой термин DTO, но это, наверное, вещь .NET - это все, что я могу понять. Подумайте о моделях представления в MVC, то же самое, черт возьми **, модели используются для передачи состояния между слоями на стороне сервера или в течение периода проводной связи. Свойства с данными. Это модели, которые вы передаете по проводу. Модели, Модели Модели. Вот и все.

Я бы хотел, чтобы глупый термин DTO не попал в наш словарный запас.