Статьи

DTO: Хипстер или Устаревший?

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

Во-первых, чтобы обойти проблему EJB-сериализации; во-вторых, они неявно определяют этап сборки, на котором все данные, которые будут использоваться для представления, маршалируются перед фактическим переходом на уровень представления. Так как EJB больше не используется в больших масштабах, можно ли отказаться от DTO? Цель этой статьи — немного рассказать о полезности DTO и ответить на этот вопрос.

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

Думая о базовой архитектуре в слоях и разделяя ее на три взаимосвязанные части, мы имеем знаменитый MVC .

Стоит отметить, что эта стратегия не является исключительной для стека веб-приложений, таких как Spring MVC и JSF. Предоставляя ваши данные в спокойном приложении с JSON, Данные JSON работают как визуализация, даже если они не дружественны к типичным пользователь.

После краткого объяснения MVC мы поговорим о преимуществах и недостатках использования DTO. Думая о многоуровневых приложениях, DTO, прежде всего, имеет целью отделить модель от представления. Размышляя о проблемах DTO:

  • Увеличивает сложность
  • Есть возможность дублирования кода
  • Добавление нового уровня влияет на уровень задержки, то есть на возможную потерю производительности.

В простых системах, которые не нуждаются в расширенной модели в качестве предпосылки, отказ от использования DTO приводит к большим преимуществам для приложения. Интересным моментом является то, что многие инфраструктуры сериализации в конечном итоге заставляют атрибуты иметь методы accessor или getter и setter, которые всегда присутствуют и являются общедоступными как обязательные, поэтому в какой-то момент это повлияет на инкапсуляцию приложения и безопасность.

Другой вариант — добавить слой DTO, который в основном гарантирует разделение вида и модели, как упоминалось ранее.

  • Это делает явным, какие поля перейдут на слой представления. Да, есть несколько аннотаций в различных структурах, которые указывают, какие поля не будут отображаться. Однако, если вы забудете записать, вы можете случайно экспортировать критическое поле, например, пароль пользователя.

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

  • Облегчает обновление базы данных . Часто очень важно провести рефакторинг, перенести базу данных, чтобы это не повлияло на клиента. Такое разделение способствует оптимизации, модификации базы данных, не влияя на визуализацию.

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

  • Еще одно преимущество заключается в простоте работы с расширенной моделью и в создании API, который одобрен пулями . Например, в моей модели я могу использовать API денег; тем не менее, в моем слое визуализации я экспортирую как простой объект только с денежным значением для визуализации. Это правильная старая строка в Java.

  • CQRS. Да, является ли разделение ответственности по командным запросам разделением ответственности за запись и чтение данных и как это сделать без DTO?

В общем, добавление слоя означает разделение и облегчение обслуживания за счет добавления большего количества классов и сложности, так как нам также нужно подумать об операции преобразования между этими слоями. Это, например, причина существования MVC, поэтому очень важно понимать, что все основано на воздействии и компромиссах или на том, что вредит тому или иному приложению или ситуации.

Отсутствие этих слоев очень плохо, это может привести к паттерну Highlander (может быть только один), из которого есть класс со всеми обязанностями. Таким же образом избыточные слои становятся луковым узором, где разработчик плачет, проходя через каждый слой.

Более частая критика в DTO работает над выполнением конверсии. Хорошая новость заключается в том, что существует несколько платформ преобразования, то есть нет необходимости вносить изменения вручную. В этой статье мы выберем тот, который является моделью .

Первый шаг — определить зависимости проекта, например, в Maven:


XML