Лучшие практики для входящих и исходящих DTO - PullRequest
1 голос
/ 25 сентября 2019

Я столкнулся с проблемой проектирования API.Рассмотрим следующий поток:

flow

Как видите, у меня есть 2 класса для представления моей модели (SomethingDTO и SomethingResponse) и 2классы для представления сторонней модели (3rdPartyRequest и 3rdPartyResponse).Я использую маппер для перевода классов моделей 3rdPArty в классы моделей.

Проблема в том, что все эти 4 класса имеют абсолютно одинаковые атрибуты.

Должен ли я повторить эти атрибутычерез все эти классы?Должен ли я иметь только один класс DTO для всего потока?

Каков наилучший метод (или шаблон) для решения этой проблемы?

Спасибо

Ответы [ 2 ]

2 голосов
/ 25 сентября 2019

Это сложный вопрос.Быть прагматичным против правильности.

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

Если у классов одинаковые атрибуты, я бы выбрал прагматический подход, предусматривающий использование одного класса на слой.Таким образом, один для вашего веб-запроса / ответа и один для третьей стороны.Но ни в коем случае «я» не смешивал бы 2 интеграционных слоя (передний и сторонний).

Наличие одного класса для всего этого пахнет очень плохо.Как я упоминал выше, потому что это смешивание слоев (или портов).

1 голос
/ 25 сентября 2019

Как я ранее ответил , использование DTO помогает отделить моделей постоянства от моделей API.Так что вы, кажется, поступаете правильно.

Проблема в том, что все эти 4 класса имеют абсолютно одинаковые атрибуты.

Всегда хорошая идея отделитьмодели вашего API из моделей сторонних API.Если сторонний API изменит свой контракт, вы не нарушите ваших клиентов.Поэтому используйте разные модели для каждого API.

И придерживайтесь картографических структур , таких как MapStruct , для уменьшения стандартного кода.Вы также можете рассмотреть Lombok для генерации методов получения, установки, equals(), hashcode() и toString().

Должен ли я повторить эти атрибуты через всеэти классы?Должен ли я иметь только один класс DTO для всего потока?

Если модели запроса и ответа содержат одинаковый набор полей , то можно начать с singleкласс для представления полезных нагрузок как запроса, так и ответа каждого API.Когда поля начинают различаться (полезная нагрузка запроса отличается от полезной нагрузки ответа), вы создаете новые модели для представления каждой полезной нагрузки.

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

...