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