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

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

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

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

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

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

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

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

вот общее правило: DTO == зло и индикатор сверхспроектированного программного обеспечения. ПОСТЕПЕННО == хороший. шаблоны 'предприятия' уничтожили мозги большого количества людей в Java мир EE. не повторяйте ошибку на земле.NET.

TL; DR:

А DTO описывает шаблон передачи состояния. ПОСТЕПЕННО ничего не описывает. Это - другой способ сказать "объект" в ООП. Это прибывает из POJO (Java), выдуманный Martin Fowler, который буквально просто описывает это как более необычное название 'объекта', потому что 'объект' не очень сексуален.

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

А ПОСТЕПЕННО является простым объектом, но что предназначено 'плоскостью', то, что это не является особенным. Это просто означает, что это - объект CLR без подразумеваемого шаблона к нему. Общее обозначение. Это не сделано работать с некоторой другой платформой. Таким образом, если бы Ваш ПОСТЕПЕННО имеет [JsonProperty] или художественные оформления EF на всем протяжении, это - свойства, например, затем это я утверждал бы, что это не ПОСТЕПЕННО.

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

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

Это, все просто возражают, но заметьте, что большинство из них обычно связывается с шаблоном. Таким образом, Вы могли назвать их "объектами", или Вы могли быть более конкретны относительно его намерения и назвать его тем, каково это. Это также, почему у нас есть шаблоны разработки; описать сложные понятия в нескольких работах. DTO является шаблоном. Совокупный корень является шаблоном, Модель Представления является шаблоном (например, MVC & MVVM). ПОСТЕПЕННО не шаблон.

А ПОСТЕПЕННО не описывает шаблон. Это - просто другой способ относиться к классам/объектам в ООП. Думайте о нем как об абстрактном понятии; они могут обращаться к чему-либо. IMO, существуют односторонние отношения, хотя, потому что, после того как объект достигает точки, где это может только служить одной цели чисто, это больше не ПОСТЕПЕННО. Например, после того как Вы повышаете свой класс с художественными оформлениями, чтобы заставить его работать с некоторой платформой, это больше не ПОСТЕПЕННО. Поэтому:

• А DTO ПОСТЕПЕННО
• , А ПОСТЕПЕННО не является DTO
• , Модель Представления А ПОСТЕПЕННО
• , А ПОСТЕПЕННО не является Моделью

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

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

POCO - это просто объект, который выполняет не зависеть от внешней структуры. Это ОБЫЧНЫЙ.

Независимо от того, имеет ли POCO поведение или нет, это несущественно.

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

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

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