POCO = Простой старый объект CLR (или лучше: класс)
DTO = Объект передачи данных
В этом посте есть разница, но, честно говоря, большинство блогов, которые я читал, описывают POCO в том, как определяется DTO: DTO - это простые контейнеры данных, используемые для перемещения данных между уровнями приложения.
POCO и DTO - это одно и то же?
Ответы:
POCO следует правилам ООП. Он должен (но не должен) иметь состояние и поведение. POCO происходит от POJO, придуманного Мартином Фаулером [ анекдот здесь ]. Он использовал термин POJO как способ сделать его более сексуальным, чтобы отвергнуть тяжелые реализации EJB. POCO следует использовать в том же контексте в .Net. Не позволяйте фреймворкам определять дизайн вашего объекта.
Единственная цель DTO - передать состояние и не должна иметь никакого поведения. См. Объяснение DTO Мартина Фаулера для примера использования этого шаблона.
Вот разница: POCO описывает подход к программированию (старомодное объектно-ориентированное программирование), где DTO - это шаблон, который используется для «передачи данных» с использованием объектов.
Хотя вы можете рассматривать POCO как DTO, вы рискуете создать анемичную модель домена, если вы это сделаете. Кроме того, существует несоответствие в структуре, поскольку DTO должны быть предназначены для передачи данных, а не для представления истинной структуры бизнес-сферы. Результатом этого является то, что DTO имеют тенденцию быть более плоскими, чем ваш реальный домен.
В домене любой разумной сложности вам почти всегда лучше создавать отдельные доменные POCO и переводить их в DTO. DDD (управляемый доменом дизайн) определяет антикоррупционный уровень (еще одна ссылка здесь , но лучше всего купить книгу ), которая является хорошей структурой, которая делает сегрегацию ясной.
источник
Возможно, для меня излишне вносить свой вклад, так как я уже изложил свою позицию в своей статье в блоге, но последний абзац этой статьи подводит итог:
Итак, в заключение, научитесь любить POCO и убедитесь, что вы не распространяете дезинформацию о том, что это то же самое, что DTO. DTO - это простые контейнеры данных, используемые для перемещения данных между уровнями приложения. POCO - это полноценные бизнес-объекты с одним требованием, чтобы они оставались невосприимчивыми к постоянству (нет методов get или save). И наконец, если вы еще не проверили книгу Джимми Нильссона, возьмите ее из местных стеков университетов. У него есть примеры на C #, и это отлично читается.
Кстати, Патрик Я прочитал POCO как статью о стиле жизни, и я полностью согласен, что это фантастическая статья. На самом деле это раздел из книги Джимми Нильссона, который я рекомендовал. Я понятия не имел, что это было доступно онлайн. Его книга действительно является лучшим источником информации, которую я нашел в POCO / DTO / Repository / и других методах разработки DDD.
источник
POCO - это просто объект, который не зависит от внешней среды. Это PLAIN.
Неважно, имеет ли POCO поведение или нет.
DTO может быть POCO, как и объект домена (который, как правило, имеет богатое поведение).
Как правило, DTO с большей вероятностью принимают зависимости от внешних структур (например, атрибутов) для целей сериализации, поскольку обычно они выходят на границу системы.
В типичных архитектурах в стиле Onion (часто используемых в широком подходе DDD) уровень домена размещается в центре, и поэтому его объекты не должны иметь зависимостей вне этого уровня.
источник
Я написал статью на эту тему: DTO против Value Object против POCO .
Короче говоря:
источник
Я думаю, что DTO может быть POCO. DTO больше относится к использованию объекта, в то время как POCO больше к стилю объекта (отделенного от архитектурных концепций).
Один из примеров, когда POCO отличается от DTO, - это когда вы говорите о POCO внутри модели вашего домена / модели бизнес-логики, которая является хорошим представлением OO вашего проблемного домена. Вы можете использовать POCO во всем приложении, но это может привести к нежелательным побочным эффектам, таким как утечка знаний. DTO, например, используются на сервисном уровне, с которым взаимодействует пользовательский интерфейс, DTO представляют собой плоское представление данных и используются только для предоставления пользовательскому интерфейсу данных и передачи изменений обратно на сервисный уровень. Уровень обслуживания отвечает за сопоставление обоих направлений DTO с объектами домена POCO.
Обновление Мартин Фаулер сказал , что этот подход является тяжелым дорога принять, и должен быть принят только при наличии значительного несоответствия между доменным слоем и пользовательским интерфейсом.
источник
Основной вариант использования DTO - возврат данных из веб-службы. В этом случае POCO и DTO эквивалентны. Любое поведение в POCO будет удалено при его возврате из веб-службы, поэтому не имеет значения, имеет ли оно поведение.
источник
Вот общее правило: DTO == зло и индикатор чрезмерно спроектированного программного обеспечения. Poco == хорошо. «корпоративные» шаблоны разрушили мозги многих людей в мире Java EE. Пожалуйста, не повторяйте ошибку в .NET Land.
источник
Классы DTO используются для сериализации / десериализации данных из разных источников. Если вы хотите десериализовать объект из источника, не имеет значения, какой это внешний источник: сервис, файл, база данных и т. Д., Возможно, вы захотите использовать только некоторую его часть, но вам нужен простой способ десериализации этих данных в объект. после этого вы копируете эти данные в модель XModel, которую хотите использовать. Сериализатор - это красивая технология для загрузки объектов DTO. Почему? вам нужна только одна функция для загрузки (десериализации) объекта.
источник
TL; DR:
DTO описывает схему передачи государства. POCO ничего не описывает. Это еще один способ сказать «объект» в ООП. Это происходит от POJO (Java), придуманного Мартином Фаулером, который буквально описывает его как причудливое имя для «объекта», потому что «объект» не очень сексуален.
DTO - это объектный паттерн, используемый для передачи состояния между интересующими слоями. Они могут иметь поведение (то есть технически может быть poco), пока это поведение не изменяет состояние. Например, у него может быть метод, который сериализует себя.
POCO - это простой объект, но под «простым» подразумевается то, что он не является особенным. Это просто означает, что это объект CLR без какого-либо подразумеваемого шаблона. Общий термин. Он не предназначен для работы с другими фреймворками. Так что, если ваш POCO имеет
[JsonProperty]или EF украшения во всех своих свойствах, например, то я бы сказал, что это не POCO.Вот несколько примеров различных типов объектов для сравнения:
Все это просто объекты, но обратите внимание, что большинство из них, как правило, привязаны к шаблону. Таким образом, вы могли бы назвать их «объектами» или вы могли бы быть более точными в отношении его намерений и называть его так, как оно есть. Это также, почему у нас есть шаблоны проектирования; описать сложные концепции в нескольких работах. DTO это шаблон. Агрегированный корень - это шаблон, View Model - шаблон (например, MVC и MVVM). POCO это не шаблон.
POCO не описывает шаблон. Это просто другой способ ссылки на классы / объекты в ООП. Думайте об этом как об абстрактном понятии; они могут относиться к чему угодно. ИМО, хотя есть односторонние отношения, потому что, как только объект достигает точки, когда он может чисто служить только одной цели, он больше не является POCO. Например, как только вы пометите свой класс украшениями, чтобы он работал с какой-то структурой, он больше не будет POCO. Следовательно:
Смысл разграничения между ними заключается в том, чтобы сохранить четкость и последовательность шаблонов, чтобы не допустить пересечения проблем и привести к тесной взаимосвязи. Например, если у вас есть бизнес-объект, который имеет методы для изменения состояния, но он также украшен украшениями EF для сохранения в SQL Server и JsonProperty, чтобы его можно было отправить обратно через конечную точку API. Этот объект будет нетерпим к изменению и, скорее всего, будет завален вариантами свойств (например, UserId, UserPk, UserKey, UserGuid, где некоторые из них помечены так, что они не сохранены в БД, а другие помечены как не сериализованные для JSON в конечной точке API).
Так что, если бы вы сказали мне, что что-то было DTO, то я бы, наверное, позаботился о том, чтобы оно никогда не использовалось ни для чего, кроме перемещения состояния вокруг. Если бы вы сказали мне, что что-то было моделью представления, то я, вероятно, удостоверился бы, что это не было сохранено в базе данных. Если бы вы сказали мне, что что-то было моделью предметной области, то я, вероятно, удостоверился бы, что она не зависит ни от чего вне домена. Но если бы вы сказали мне, что что-то было POCO, вы бы вообще ничего мне не рассказывали.
источник
Даже не называй их DTO. Они называются моделями .... Период. Модели никогда не имеют поведения. Я не знаю, кто придумал этот тупой термин DTO, но это, наверное, вещь .NET - это все, что я могу понять. Подумайте о моделях представления в MVC, то же самое, черт возьми **, модели используются для передачи состояния между слоями на стороне сервера или в течение периода передачи, все они модели. Свойства с данными. Это модели, которые вы передаете по проводу. Модели, Модели Модели. Вот и все.
Я хотел бы, чтобы глупый термин DTO отошел от нашего словаря.
источник