Что такое объект передачи данных (DTO)?

С помощью MVC объекты передачи данных часто используются для сопоставления моделей предметной области с более простыми объектами, которые в конечном итоге будут отображаться в представлении.

Из Википедии:

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

Принцип, лежащий в основе объекта передачи данных, заключается в создании новых объектов данных, которые включают только те свойства, которые необходимы для конкретной транзакции данных.

Преимущества включают:

Повышение безопасности передачи данных. Уменьшите размер передаваемых данных, если удалите все ненужные данные.

Подробнее: https://www.codenerd.co.za/what-is-data-transfer-objects

Все кредиты принадлежат Рику-Андресону

Рабочие приложения обычно ограничивают вводимые и возвращаемые данные с помощью подмножества модели. Для этого есть несколько причин, и безопасность является одной из основных. Подмножество модели обычно называется объектом передачи данных (DTO), моделью ввода или моделью представления.

DTO можно использовать для:

• Предотвратить чрезмерное количество публикаций.
• Скрыть свойства, которые клиенты не должны просматривать.
• Опустите некоторые свойства, чтобы уменьшить размер полезной нагрузки.
• Сглаживайте графы объектов, содержащие вложенные объекты.
• Сглаженные графы объектов могут быть более удобными для клиентов.

Практическая реализация подхода DTO, Рик-Андресон в Microsoft Web API лучшие учебные пособия и практики с использованием C # и ASP .Net Core 5:

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

DefN

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

Напротив, динамическая модель или «мешок свойств» решает проблему моделирования записи данных, когда производственный процесс создается во время выполнения.

Квар

DTO можно смоделировать с помощью полей или свойств, но кто-то изобрел очень полезный контейнер данных, называемый Cvar. Это ссылка на значение. Когда DTO моделируется с помощью того, что я называю ссылочными свойствами, модули могут быть настроены для совместного использования кучи памяти и, таким образом, совместной работы над ней. Это полностью исключает передачу параметров и связь O2O из вашего кода. Другими словами, DTO, имеющие ссылочные свойства, позволяют коду достичь нулевого связывания.

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

Источник: http://www.powersemantics.com/

Динамические DTO - необходимый компонент динамического программного обеспечения. Чтобы создать динамический процесс, один шаг компилятора - привязать каждую машину в сценарии к ссылочным свойствам, которые сценарий определяет. Динамический DTO создается путем добавления Cvars в коллекцию.

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

Разногласия

Примечание: поскольку Wix назвал использование DTO для организации параметров «анти-паттерном», я выскажу авторитетное мнение.

    return View(model);  // MVC disagrees

Моя совместная архитектура заменяет шаблоны проектирования. Обратитесь к моим статьям в Интернете.

Параметры обеспечивают немедленное управление машиной для стекирования кадров. Если вы используете непрерывный контроль и, следовательно, не нуждаетесь в немедленном контроле, ваши модули не нуждаются в параметрах. В моей архитектуре ничего нет. Конфигурация машин (методов) в процессе добавляет сложность, но также увеличивает ценность (производительность), когда параметры являются типами значений. Однако параметры ссылочного типа заставляют потребителя вызывать промахи кеша для получения значений из кучи в любом случае - поэтому просто настройте потребителя со ссылочными свойствами. Факт из машиностроения: опора на параметры - это своего рода предварительная оптимизация, потому что сама обработка (изготовление компонентов) - это отходы. Обратитесь к моей статье W для получения дополнительной информации. http://www.powersemantics.com/w.html.

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

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

По сути, нет ничего плохого в моделировании обработки как кучке бесполезных офисных работников, которые пересылают друг другу электронную почту, не сохраняя следа электронной почты, за исключением всей дополнительной работы и головной боли, которую она создает при решении проблем с логистикой и возвратом. Правильно смоделированный распределенный процесс прикрепляет к продукту документ (активная маршрутизация), в котором описывается, из каких операций он пришел и к которым будет переходить. Активная маршрутизация - это копия исходной маршрутизации процесса, которая записывается до начала процесса. В случае дефекта или другого экстренного изменения активная маршрутизация модифицируется и включает в себя этапы работы, на которые она будет отправлена. Таким образом, это составляет весь труд, затраченный на производство.

Я бы объяснил DTO своему ребенку как

Мой сын Data Transfer Object (он же DTO) используется для инкапсуляции данных, которые мы отправляем из одного приложения (api и т. Д.) В другое
Используйте DTO для определения интерфейсов для ввода и вывода для вашей системы

Под системой в этом контексте я имею в виду, что у вас есть несколько конечных точек (веб-приложения, api и т. Д.), Которые вместе образуют систему