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

StackOverflow https://stackoverflow.com/questions/725348

  •  05-09-2019
  •  | 
  •  

Вопрос

POCO = Plain Old 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 против объекта значения против POCO.

Суммируя:

  • DTO != Объект значения
  • ДТО ⊂ ПОКО
  • Объект значения ⊂ POCO

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

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

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

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

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

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

ТЛ;ДР:

DTO описывает шаблон передачи состояния.POCO ничего не описывает.Это еще один способ сказать «объект» в ООП.Оно происходит от POJO (Java), придуманного Мартином Фаулером, который буквально просто описывает его как более красивое имя для «объекта», потому что «объект» не очень привлекателен.

DTO — это шаблон объекта, используемый для передачи состояния между проблемными уровнями.Они могут иметь поведение (т.е.технически может быть poco), пока такое поведение не меняет состояние.Например, у него может быть метод, который сериализует сам себя.

POCO — это простой объект, но под «простым» подразумевается то, что он не является чем-то особенным.Это просто означает, что это объект CLR без какого-либо подразумеваемого шаблона.Общий термин.Он не предназначен для работы с какой-либо другой структурой.Итак, если ваш POCO имеет [JsonProperty] или украшения EF по всему его свойствам, например, тогда я бы сказал, что это не POCO.

Вот несколько примеров различных типов шаблонов объектов для сравнения:

  • Посмотреть модель:используется для моделирования данных для представления.Обычно содержит аннотации к данным для облегчения привязки и проверки.В MVVM он также выступает в роли контроллера.Это больше, чем DTO
  • Объект значения:используется для представления значений
  • Совокупный корень:используется для управления состоянием и инвариантами
  • Обработчики:используется для ответа на событие/сообщение
  • Атрибуты:используется в качестве украшения для решения сквозных проблем
  • Услуга:используется для выполнения сложных задач
  • Контроллер:используется для управления потоком запросов и ответов
  • Фабрика:используется для настройки и/или сборки сложных объектов для использования, когда конструктор недостаточно хорош.Также используется для принятия решений о том, какие объекты необходимо создать во время выполнения.
  • Репозиторий/ДАО:используется для доступа к данным

Это всего лишь объекты, но обратите внимание, что большинство из них обычно привязаны к шаблону.Таким образом, вы можете называть их «объектами» или более конкретно указать их назначение и назвать их тем, чем они являются.Именно поэтому у нас есть шаблоны проектирования;описать сложные понятия в нескольких работах.DTO — это шаблон.Агрегатный корень — это шаблон, Модель представления — это шаблон (например,MVC и MVVM).POCO — это не шаблон.

POCO не описывает шаблон.Это просто другой способ обращения к классам/объектам в ООП.Думайте об этом как об абстрактной концепции;они могут относиться к чему угодно.ИМХО, существует односторонняя связь, потому что, как только объект достигает точки, в которой он может чисто служить только одной цели, он больше не является POCO.Например, как только вы разметите свой класс с помощью украшений, чтобы он работал с какой-либо структурой, он перестанет быть POCO.Поэтому:

  • DTO — это POCO
  • POCO — это не DTO
  • Модель представления — это POCO
  • POCO не является моделью представления

Цель проведения различия между этими двумя понятиями заключается в сохранении четкости и последовательности моделей, чтобы не пересекать проблемы и не приводить к тесной связи.Например, если у вас есть бизнес-объект, который имеет методы для изменения состояния, но также чертовски украшен украшениями EF для сохранения в SQL Server И JsonProperty, чтобы его можно было отправить обратно через конечную точку API.Этот объект будет нетерпим к изменениям и, скорее всего, будет усеян вариантами свойств (например,UserId, UserPk, UserKey, UserGuid, где некоторые из них помечены для того, чтобы их нельзя было сохранять в БД, а другие помечены для того, чтобы не сериализоваться в JSON в конечной точке API).

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top