Відповіді:
Об'єкт передачі даних - це об'єкт, який використовується для інкапсуляції даних та передачі їх з однієї підсистеми програми в іншу.
DTO найчастіше використовуються рівнем Services у додатку N-Tier для передачі даних між собою та рівнем інтерфейсу користувача. Основна перевага тут полягає в тому, що це зменшує кількість даних, які потрібно надсилати по всій мережі в розподілених додатках. Вони також роблять чудові моделі за схемою MVC.
Іншим використанням для DTO може бути інкапсуляція параметрів для викликів методів. Це може бути корисно, якщо метод має більше 4 або 5 параметрів.
Використовуючи схему DTO, ви також використовуєте збирачі DTO. Асемблери використовуються для створення DTO з об'єктів домену, і навпаки.
Перетворення з об’єкта домену в DTO і назад може бути дорогим процесом. Якщо ви не створюєте розподілену програму, ви, мабуть, не побачите великих вигод від шаблону, як пояснює тут Мартін Фаулер
Визначення DTO можна знайти на сайті Мартіна Фаулера . DTO використовуються для передачі параметрів методам і як типи повернення. Дуже багато людей використовують такі в інтерфейсі, але інші надувають доменні об’єкти від них.
DTO є тупим об'єктом - він просто містить властивості, має getters і setters, але немає жодної іншої логіки будь-якого значення (крім, можливо, порівняння () або рівності () реалізації).
Зазвичай модельні класи в MVC (якщо тут .net MVC) - це DTO, або колекції / агрегати DTO
Загалом об'єкти цінності повинні бути незмінними. Як і об'єкти Integer або String в Java. Ми можемо використовувати їх для передачі даних між програмними рівнями. Якщо шари програм або послуги, що працюють у різних віддалених вузлах, наприклад, у середовищі мікросервісів або у застарілому додатку Java Enterprise. Ми повинні зробити майже точні копії двох класів. Тут ми зустріли DTO.
|-----------| |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------| |--------------|
У застарілих системах Java Enterprise Systems DTO можуть містити в собі різні речі EJB.
Я не знаю, це найкраща практика чи ні, але я особисто використовую ціннісні об’єкти у своїх весняних проектах MVC / Boot:
|------------| |------------------| |------------|
-> Form | | -> Form | | -> Entity | |
| Controller | | Service / Facade | | Repository |
<- View | | <- View | | <- Entity / Projection View | |
|------------| |------------------| |------------|
Шар контролера не знає, що таке сутність. Він спілкується з об'єктами форми та переглядає значення . Об'єкти форми мають анотації валідації JSR 303 (наприклад, @NotNull), а об'єкти перегляду значення мають анотації Джексона для користувацької серіалізації. (наприклад, @JsonIgnore)
Службовий рівень спілкується з шаром сховища за допомогою об'єктів Entity. Об'єкти суб'єктів господарювання мають анотації JPA / Hibernate / Spring Data. Кожен шар спілкується лише з нижчим шаром. Міжшаровий зв'язок заборонений через кругову / циклічну залежність.
User Service ----> XX CANNOT CALL XX ----> Order Service
Деякі рамки ORM мають можливість проекції за допомогою додаткових інтерфейсів або класів. Таким чином сховища можуть повертати об'єкти 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 ...
}
Але вам слід повернути список страждаючих користувачів, який містить лише id, ім'я, прізвище. Потім ви можете створити об'єкт перегляду значення для проекції ORM.
public final class UserListItemView {
private String id;
private String firstname;
private String lastname;
// Accessors ...
}
Ви можете легко отримати болісний результат із шару сховища. Завдяки весні ви також можете використовувати просто інтерфейси для проекцій.
List<UserListItemView> find(Pageable pageable);Не хвилюйтесь, що інші BeanUtils.copyметоди конверсійних операцій спрацьовують чудово.
GET/ POST/ що завгодно) або використання веб-сервісу за допомогою SOA тощо), ви не бажаєте передавати об'єкт великого розміру з кодом, який не потрібен кінцева точка, буде споживати дані та уповільнюватиме передачу.За допомогою MVC об'єкти передачі даних часто використовуються для зіставлення моделей домену на більш прості об'єкти, які в кінцевому підсумку будуть відображатися поданням.
З Вікіпедії :
Об'єкт передачі даних (DTO), раніше відомий як об'єкти цінності або VO, є схемою проектування, що використовується для передачі даних між підсистемами програмного забезпечення. DTO часто використовуються спільно з об'єктами доступу до даних для отримання даних із бази даних.
Об'єкт передачі даних (DTO) описує "об'єкт, який здійснює передачу даних між процесами" (Wikipedia) або "об'єкт, який використовується для інкапсуляції даних та надсилання їх з однієї підсистеми програми в іншу" (відповідь на переповнення стека).
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 анемічною моделлю домену, тобто вона не має функціональних можливостей, але це передбачає, що об'єкт повинен володіти даними, з якими він взаємодіє. Ця концептуальна модель потім змушує вас доставляти дані між об'єктами, що є моделлю для розподіленої обробки. Однак на виробничій лінії кожен крок може отримати доступ до кінцевого продукту та змінити його, не володіючи ним і не контролюючи його. У цьому різниця між розподіленою та інтегрованою обробкою. Виробництво відокремлює продукт від операцій та логістики.
Немає нічого поганого в моделюванні обробки як купа непотрібних офісних службовців, які працюють електронною поштою один з одним, не зберігаючи слід електронної пошти, за винятком усієї додаткової роботи та головного болю, який вона створює при роботі з логістикою та проблемами повернення. Правильно модельований розподілений процес приєднує документ (активну маршрутизацію) до продукту, що описує, з яких операцій він вийшов і на який піде. Активна маршрутизація - це копія маршрутизації джерела процесу, яка записується до початку процесу. У разі дефекту чи іншої надзвичайної зміни активну маршрутизацію модифікують, щоб включити кроки операції, на які вона буде надіслана. Потім це припадає на всю працю, яка пішла на виробництво.