Який сенс використання DTO (об'єктів передачі даних)?

У чому сенс використання DTO і чи це застаріла концепція? Я використовую POJO s на рівні перегляду для передачі та збереження даних. Чи можна розцінювати ці POJO як альтернативу DTO?

DTO - це шаблон, і реалізація (POJO / POCO) не залежить. DTO каже, оскільки кожен дзвінок на будь-який віддалений інтерфейс дорогий, відповідь на кожен дзвінок повинна приносити якомога більше даних. Отже, якщо для отримання даних для певної задачі потрібно декілька запитів, дані, що підлягають передачі, можуть бути об'єднані в DTO, так що лише один запит може принести всі необхідні дані. Каталог шаблонів архітектури корпоративних додатків містить більше деталей.

ЗНО - це фундаментальне поняття, не застаріле.

DTO як концепція (об'єкти, метою яких є збір даних, що повертаються клієнтові сервером), безумовно, не застаріла.

Що є дещо застарілим , є поняття того DTOs , які не містять ніякої логіки взагалі, використовуються тільки для передачі даних і «карту» з об'єктів предметної області перед передачею клієнтові, і відображається для перегляду моделей , перш ніж передати їх в шар дисплея. У простих програмах об'єкти домену часто можуть бути безпосередньо використані як DTO і передані безпосередньо на рівень відображення, щоб існувала лише одна уніфікована модель даних. Для більш складних додатків ви не хочете виставляти клієнту всю доменну модель, тому необхідне відображення від доменних моделей до DTO. Наявність окремої моделі перегляду, що дублює дані з DTO, майже ніколи не має сенсу.

Однак причина цього поняття застаріла, а не просто невірна, полягає в тому, що деякі (в основному старіші) рамки / технології цього вимагають, оскільки їх доменні та переглядні моделі не є POJOS, а замість цього прив’язані безпосередньо до рамки.

Найголовніше, що Entity Beans в J2EE до стандарту EJB 3 не були POJO, а замість цього були проксі-об'єкти, побудовані сервером додатків - просто неможливо було надіслати їх клієнтові, тому у вас не було іншого вибору щодо вилучення окремого шару DTO. - це було обов’язково.

Хоча DTO не є застарілим шаблоном, він часто застосовується без потреби, що може зробити його застарілим.

Найбільш зловживаний зразок у спільноті Java Enterprise - це DTO. DTO був чітко визначений як вирішення проблеми розподілу. DTO мав бути грубозернистим контейнером даних, який ефективно переносить дані між процесами (ярусами). ~ Адам Біен

Наприклад, скажіть, що у вас є JSF ManagedBean. Поширене питання полягає в тому, чи повинен боб безпосередньо посилатись на сутність JPA або він повинен підтримувати посилання на якийсь посередницький об'єкт, який згодом перетворюється на Сутність. Я чув про цей посередницький об'єкт, який називається DTO, але якщо ваші ManagedBeans та Entities працюють в межах одного JVM, використання схеми DTO мало користі.

Розглянемо примітки щодо перевірки квасолі. Ваші організації JPA, ймовірно, помічені за допомогою перевірок @NotNull та @Size. Якщо ви використовуєте DTO, вам потрібно повторити ці перевірки у вашому DTO, щоб клієнтам, які використовують ваш віддалений інтерфейс, не потрібно надсилати повідомлення, щоб дізнатися, що вони не виконали основну перевірку. Уявіть собі всю додаткову роботу з копіювання анотацій перевірки Bean між вашим DTO та Entity, але якщо ваш View і Entities працюють в межах одного JVM, не потрібно братися за цю додаткову роботу: просто використовуйте Entities.

Посилання IAmTheDude на Каталог шаблонів архітектури прикладних програм підприємства надає стисле пояснення DTO, і тут я знайшов більше посилань:

• ЯК РОБИТИ З ПАРТЕРНЯМ J2EE І ПРОЕКТУВАННЯ
• Як використовувати DTO в JSF + Spring + Hibernate
• Плюси і мінуси об'єктів передачі даних

Абсолютно ні! Нещодавно я засвоїв уроки щодо кращого використання DTO, а не вашого бізнес-об’єкта, який ви використовуєте (можливо, пов'язаний з вашим картографічним механізмом ORM).

Однак просто використовуйте їх, коли їх доцільно використовувати, а не лише заради їх використання, оскільки вони згадуються в книзі хороших зразків.
Типовий приклад, який мені просто приходить в голову, - це коли ви виставляєте якийсь інтерфейс третім сторонам. У такому сценарії ви хочете зберегти обмінювані об'єкти досить стабільними, чого зазвичай можна добре досягти за допомогою DTO.

Я вважаю, що DTO є особливо корисним - це вміст логіки для відповідей API. За допомогою цього шаблону легко керувати різними типами відповідей від об'єктів до різних форматів перевіряється. Використовуючи цю схему в моїй теперішній ролі, ми змогли почати тестувати формати відповідей для наших API, що було цінним, оскільки наш стек стає все більш ізоморфним для різних клієнтів (http / mobile). Однозначно не застаріла.