Что такое объект передачи данных?
Что такое объект передачи данных?
В MVC есть модели классов DTO, и если нет, то в чем различия и нужны ли нам оба?
13 ответов
Объект передачи данных - это объект, который используется для инкапсуляции данных и отправки их из одной подсистемы приложения в другую.
DTO чаще всего используются уровнем служб в приложении N-уровня для передачи данных между собой и уровнем пользовательского интерфейса. Основным преимуществом здесь является то, что он уменьшает объем данных, которые необходимо передавать по проводам в распределенных приложениях. Они также делают отличные модели в шаблоне MVC.
Другое использование DTO может заключаться в инкапсуляции параметров для вызовов методов. Это может быть полезно, если метод принимает более 4 или 5 параметров.
При использовании шаблона DTO вы также должны использовать ассемблеры DTO. Ассемблеры используются для создания DTO из доменных объектов и наоборот.
Преобразование из Доменного объекта в DTO и обратно может быть дорогостоящим процессом. Если вы не создаете распределенное приложение, вы, вероятно, не увидите каких-либо значительных преимуществ от шаблона, как объясняет здесь Мартин Фаулер
Определение DTO можно найти на сайте Мартина Фаулера. DTO используются для передачи параметров в методы и в качестве возвращаемых типов. Многие используют их в пользовательском интерфейсе, но другие раздувают из них доменные объекты.
DTO - это тупой объект - он просто содержит свойства и имеет геттеры и сеттеры, но никакой другой логики какого-либо значения (кроме, может быть, реализации Compare () или Equals()).
Обычно модельные классы в MVC (при условии.net MVC здесь) являются DTO или коллекциями / агрегатами DTO
В общем случае объекты значения должны быть неизменными. Как объекты Integer или String в Java. Мы можем использовать их для передачи данных между уровнями программного обеспечения. Если программные уровни или службы работают в разных удаленных узлах, например в среде микросервисов или в устаревшем Java Enterprise App. Мы должны сделать почти точные копии двух классов. Именно здесь мы встретили DTO.
|-----------| |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------| |--------------|
В устаревших Java Enterprise Systems DTO могут содержать различные EJB-компоненты.
Я не знаю, является ли это лучшей практикой или нет, но я лично использую объекты Value в своих проектах Spring MVC/Boot, например:
|------------| |------------------| |------------|
-> Form | | -> Form | | -> Entity | |
| Controller | | Service / Facade | | Repository |
<- View | | <- View | | <- Entity / Projection View | |
|------------| |------------------| |------------|
Уровень контроллера не знает, что это за сущности. Он связывается с объектами формы и представления значений. Объекты формы имеют аннотации JSR 303 Validation (например, @NotNull) и объекты View Value имеют аннотации Джексона для настраиваемой сериализации. (например, @JsonIgnore)
Уровень сервиса связывается с уровнем репозитория с помощью Entity Objects. На объектах сущностей есть аннотации JPA/Hibernate/Spring Data. Каждый уровень связывается только с нижним уровнем. Межуровневая связь запрещена из-за циклической / циклической зависимости.
User Service ----> XX CANNOT CALL XX ----> Order Service
Некоторые ORM Frameworks имеют возможность проецирования с использованием дополнительных интерфейсов или классов. Таким образом, репозитории могут возвращать объекты View напрямую. Там для вас не нужны дополнительные преобразования.
Например, это наш пользовательский объект:
@Entity
public final class User {
private String id;
private String firstname;
private String lastname;
private String phone;
private String fax;
private String address;
// Accessors ...
}
Но вы должны вернуть список пользователей с нумерацией страниц, в который входят только имя, имя, фамилия. Затем вы можете создать объект View Value для проекции ORM.
public final class UserListItemView {
private String id;
private String firstname;
private String lastname;
// Accessors ...
}
Вы можете легко получить постраничный результат из слоя хранилища. Благодаря весне вы также можете использовать только интерфейсы для проекций.
List<UserListItemView> find(Pageable pageable);
Не беспокойтесь о других операциях конвертации BeanUtils.copy метод работает просто отлично.
1) Для меня лучший ответ на вопрос, что такое DTO, состоит в том, что DTO - это простые объекты, которые не должны содержать никакой бизнес-логики или реализации методов, которые потребовали бы тестирования.
2) Обычно ваша модель (использующая шаблон MVC) - это интеллектуальные модели, и они могут содержать множество / несколько методов, которые выполняют несколько различных операций для этой модели конкретно (не бизнес-логика, это должно быть на контроллерах). Однако когда вы передаете данные (например, вызываете конечную точку REST (GET/POST/ что угодно) откуда-либо, или используете веб-сервис с использованием soa и т. Д.), Вы не хотите передавать объект большого размера с кодом, который не является необходим для конечной точки, будет потреблять данные и замедлять передачу.
Все кредиты принадлежат
Рабочие приложения обычно ограничивают вводимые и возвращаемые данные с помощью подмножества модели. Этому есть несколько причин, и безопасность является одной из основных. Подмножество модели обычно называется объектом передачи данных ( DTO ), моделью ввода или моделью представления.
DTO может использоваться для:
- Предотвратить чрезмерное количество публикаций.
- Скрыть свойства, которые клиенты не должны просматривать.
- Опустите некоторые свойства, чтобы уменьшить размер полезной нагрузки.
- Сглаживайте графы объектов, содержащие вложенные объекты.
- Сглаженные графы объектов могут быть более удобными для клиентов.
Практическая реализация подхода DTO, Рику-АндресонуРик-Андресон из лучших руководств и практик Microsoft Web APIs с использованием C # и ASP .Net Core 5:
С помощью MVC объекты передачи данных часто используются для отображения моделей предметной области на более простые объекты, которые в конечном итоге будут отображаться представлением.
Из Википедии:
Объект передачи данных (DTO), ранее известный как объекты значений или VO, является шаблоном проектирования, используемым для передачи данных между подсистемами программных приложений. DTO часто используются в сочетании с объектами доступа к данным для извлечения данных из базы данных.
Принцип, лежащий в основе объекта передачи данных, заключается в создании новых объектов данных, которые включают только необходимые свойства, необходимые для конкретной транзакции данных.
Преимущества включают:
Повышение безопасности передачи данных. Уменьшите размер передаваемых данных, если удалите все ненужные данные.
Подробнее: https://www.codenerd.co.za/what-is-data-transfer-objects
Некоторые программисты используют DTO, чтобы различать конечные данные объекта, которые будут передаваться через API. Таким образом, это в основном объект полезной нагрузки для конечной точки. Например, вы можете назвать свой объект значений контактной формы, который вы передаете на сервер, как
contactFormDto or contactFromPayload, тогда вы или любой другой программист знаете, что у вас есть в этом объекте окончательная форма данных, которые будут путешествовать по сети.
Я бы объяснил DTO своему ребенку как
Объект передачи данных моего сына (он же DTO) используется для инкапсуляции данных, которые мы отправляем из одного приложения (api и т. Д.) В другое.
Используйте DTO для определения интерфейсов для ввода и вывода для вашей системы.Под системой в этом контексте я имею в виду, что у вас есть несколько конечных точек (веб-приложения, api и т. Д.), Которые вместе образуют систему
Объект передачи данных (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 существуют вопреки общепринятому мнению DonotRepeatYourself. Будьте очень осторожны и абсолютно уверены, что вам нужен DTO