POCO = Обычный объект CLR (или лучше: класс)
DTO = объект передачи данных
В этой статье есть разница, но, откровенно говоря, большинство блогов, которые я прочитал, описывают POCO в том, как определяется DTO: DTO - это простые контейнеры данных, используемые для перемещения данных между слоями приложения.
Являются ли POCO и DTO то же самое?
A POCO следует правилам ООП. Это должно (но не обязательно) иметь состояние и поведение. POCO поступает из POJO, придуманного здесь здесь. [Info] = > nerferrer > . Он использовал термин POJO как способ сделать его более сексуальным, чтобы отклонить каркасные сильные реализации EJB. POCO следует использовать в том же контексте в .Net. Не позволяйте фреймворкам диктовать дизайн вашего объекта.
Цель DTO - передать состояние и не должно иметь никакого поведения. См. Объяснение DTO на примере использования этого шаблона Мартин Фаулер
Здесь разница: POCO описывает подход к программированию (хорошее старомодное объектно-ориентированное программирование), где DTO - это шаблон, который используется для передачи данных с использованием объекты.
В то время как вы можете обращаться с POCOs, такими как DTO, вы рискуете создать уровень защиты от коррупции (другая ссылка здесь, но лучше всего купить книгу), что является хорошей структурой, которая делает сегрегацию понятной.
Это, вероятно, излишний для меня, поскольку я уже заявил о своей позиции в своей статье в блоге, но последний абзац этой статьи подводит итог:
Итак, в заключение, научитесь любить POCO и убедитесь, что вы не распространяете какую-либо дезинформацию о том, что это то же самое, что и DTO. DTO - это простые контейнеры данных, используемые для перемещения данных между уровнями приложения. POCOs - это полноценные бизнес-объекты с одним требованием, чтобы они были невосприимчивы к сохранению (без методов получения или сохранения). Наконец, если вы еще не проверили книгу Джимми Нилсонса, заберите ее из своих локальных университетских стеков. Он имеет примеры в С# и отличное чтение.
BTW, Patrick Я прочитал статью POCO как Lifestyle, и я полностью согласен, что это фантастическая статья. Это действительно раздел из книги Джимми Нильсона, которую я рекомендовал. Я понятия не имел, что он доступен в Интернете. Его книга действительно является лучшим источником информации, которую я нашел в POCO/DTO/Repository/и других методах разработки DDD.
POCO - это просто объект, который не зависит от внешней структуры. Это PLAIN.
Независимо от того, имеет ли POCO поведение или нет, это несущественно.
DTO может быть POCO, как объект домена (который обычно будет богат поведением).
Обычно DTO с большей вероятностью принимают зависимости от внешних фреймворков (например, атрибутов) для целей сериализации, поскольку они обычно выходят на границе системы.
В типичных архитектурах стиля Onion (часто используемых в рамках подхода с широким DDD) слой домена размещается в центре и поэтому его объекты на данный момент не должны иметь зависимости вне этого уровня.
Я написал статью для этой темы: DTO vs Value Object vs POCO.
Короче:
Я думаю, что DTO может быть POCO. DTO больше относится к использованию объекта, тогда как POCO больше относится к стилю объекта (отделен от архитектурных концепций).
Один пример, где POCO - это нечто иное, чем DTO, - это когда вы говорите о POCO внутри вашей модели модели домена/бизнес-логики, что является хорошим представлением OO вашего проблемного домена. Вы можете использовать POCO на протяжении всего приложения, но это может иметь некоторый нежелательный побочный эффект, такой утечки знаний. DTO, например, используются на уровне обслуживания, с которым взаимодействует пользовательский интерфейс, DTO - это плоское представление данных и используются только для предоставления пользовательского интерфейса данных и передачи изменений обратно на уровень обслуживания. Уровень обслуживания отвечает за сопоставление DTO в обоих направлениях с объектами домена POCO.
Обновить Мартин Фаулер сказал, что этот подход является тяжелым путем, и его следует принимать только в том случае, если является значительным несоответствием между доменным уровнем и пользовательским интерфейсом.
вот общее правило: DTO == зло и индикатор переработанного программного обеспечения. ПОКО == хорошо. "корпоративные" модели разрушили мозги многих людей в мире Java EE. пожалуйста, не повторяйте ошибку на земле .NET.
Основным вариантом использования DTO является возврат данных из веб-службы. В этом случае POCO и DTO эквивалентны. Любое поведение в POCO будет удалено, когда оно будет возвращено из веб-службы, поэтому на самом деле не имеет значения, имеет ли он поведение.
Классы DTO используются для сериализации/десериализации данных из разных источников. Когда вы хотите десериализовать объект из источника, не имеет значения, какой внешний источник он имеет: служба, файл, база данных и т.д., Вы можете использовать только часть этого, но вы хотите, чтобы простой способ десериализовать эти данные на объект. после этого вы копируете эти данные в XModel, который хотите использовать. Сериализатор - прекрасная технология для загрузки объектов DTO. Зачем? вам нужна только одна функция для загрузки (десериализации) объекта.
Не называйте их DTO. Они называются Модели.... Период. Модели никогда не имеют поведения. Я не знаю, кто придумал этот немой термин DTO, но это, должно быть,.NET, это все, что я могу понять. Подумайте о моделях просмотра в MVC, том же самом, что и в случае с дамбой **, модели используются для передачи состояния между серверами слоев или в течение периода проводов, все они являются моделями. Свойства с данными. Это модели, которые вы проходите через провод. Модели, модели. Это.
Я хочу, чтобы глупый термин DTO ушел от нашего словаря.