Хорошо ли использовать DTO в качестве объекта реквеста для api?

Question

[Sergey Ilichev]

Добрый вечер коллеги!

Из заголовка не совсем понятно, что я имею ввиду, поэтому поясню тут.

Мне посоветовали во время рефакторинга наших микросервисов использовать в api не кучу параметров у метода, а просто передавать туда DTO объект, дескать это унифицирует запросы к api. Вроде интересно, но не особо понимаю смысл (щас ночью уже не спросить коллегу). Во первых не понятно, как допустим на основе этого потом другие разработчики должны понимать что нужно передавать туда. Ну да, допустим это наш микросервис и я тут создам в микросервисе А DTO и буду слать его в метод микросервиса Б, типа могу посмотреть что за поля описаны в DTO, установить их и отправить объект. А, если допустим разработчик не знает ничего про этот DTO? Он просто видит что метод сервиса Б принимает какой-то DTO, а что там в нем должно быть не глядя код не поймешь.

Я не знаком пока особо с Symphony, но коллега мне написал, что типа можно использовать некий param конвертер для этих целей. Я стал гуглить что это такое и нашел только в отношении симфони это выражение и как я понимаю на Yii это не перенести, тут все ручками нужно делать, то есть создавать эти DTO. Да и если бы все таки можно было бы, я честно говоря, не вижу профита.

Если кто понимает, что коллега имел ввиду и почему это вообще считается удобным, расскажите пожалуйста.

Answer 1

[Максим]

Сложно понять Вашу картину и что имел ввиду Ваш коллега. Об этом лучше спросить самого коллегу. Однако постараюсь помыслить на эту тему...

1. Конкретно DTO не совсем применима к API в чистом виде и работе с ней. Более правильно в запрос кидать json, а вот этот json уже маппить на вашу DTO, в которой будет высокоуровневая валидация от симфони и php7.4. Пример И само DTO.

2. Так как у вас система микросервисная, то DTO передавать по сети точно не нужно. Вы можете использовать DTO внутри своего приложения, но не использовать его по сети. DTO позволяет Вам в сервис/хэндлер/команду передавать не сам Request и не кучу параметров, а своё DTO, которая должна создаваться на основе запроса. Таким образом вы отделяете слои и ответственности. При изменении названий параметров DTO не обязательно их менять в API и наоборот. Нет зависимости и это хорошо! Так же хорошо и для тестируемости.

3. Если вы упомянули ParamConverter это по сути конвектор параметров, но опять же на уровне приложения, а не между запросами сети) Об использовании его можно почитать в документации симфони. С помощью него можно указать в методе DTO, которую он принимает, а конвектор, написанный вами, знает как это DTO создать на основе ваших переданных данных. То есть вы не DTO передаёте в запрос, а те же параметры, просто этот конвектор делает вам из этих параметров DTO. Использовать его или нет - дело ваше. Вы правильно подметили, что в Yii2 такого нет. Можно заморочиться написать свой, но смысла от этого нет вообще) Использовать DTO я бы рекомендовал. Так как профит будет: разделение слоев, меньшая связанность и возможность валидации. А вот использовать конвектор - решение команды или разработчика. Оно позволяет вам создать вашу DTO на основе переданных параметров. Параметры никуда не денутся, они просто сразу лягут в DTO это один профит - чище код.

Comments

[vitaly_74]

нраица

[Sergey Ilichev]

Спасибо, хороший ответ)

Answer 2

[Daria Motorina]

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

Comments

[Sergey Ilichev]

А вы говорите, что в DTO может быть логика типа валидации? Я думал (читал), что в DTO максимум может быть валидация типа параметров при создании объекта. Например в php 7.4 это делается за счет указания типа свойства класса, а в версиях ниже кастомно, например на основе php доков. Или там может быть другая логика по мимо этого как в фабрике?

А в симфони это происходит автоматически? То есть приходит запрос в метод api и уже на основе этого формируется заданный как уточнение типа у аргумента функции DTO объект или как-то по другому? Если так, то значит там все api функции для работы такого механизма тоже должны иметь один параметр SomeDto $dto?

Спасибо за ваш ответ.

[Sergey Ilichev]

И еще все-таки вопросик - как по факту решается проблема понимания того, что вообще метод должен получать? Ну допустим смотрит другой разработчик на этот метод, там один параметр, какой-то $someDtoObject. На основе этого вообще можно тот же сваггер построить?

[Sergey Ilichev]

Я просто может не так понимаю, но не вижу профита от этого.

Допустим у меня есть метод в сервисе А, который принимает параметры (array $filters, int $offset, int $limit)

Я в сервисе Б создаю массив [$filters, 0, 10] и передаю его курлом в функцию. Все просто.

Предположим, что используется DTO.

Тот же метод в сервисе А, только теперь непонятная сигнатура типа ($someDtoObject)

$requestObject = SomeDtoRequest::makeDtoObject(['filters' => $filters, 'offset' => 0, 'limit' => 10]);
И опять отправляем курлом.

Вопрос - как вообще сервис A будет ругелировать, что это вообще за $someDtoObject, какого он типа? И как разработчик сторонний использующий этот метод поймет что в этом объекте должно быть?

Я себе представляю использование DTO так, что создавать такие объекты нужно для полученного респонса например. То есть получили ответ, завернули его в DTO и дальше используем. Но в реквесте не понятно как это использовать.

[Daria Motorina]

Sergey Ilichev, в симфони возможно добавить валидацию в dto - просто там механизм валидации можно записать а уровне специальных докблоков поверх каждого свойства (validation constraints из Validator Component) и вроде там еще doctrine annotations нужно установить) получается в дто можно написать правила валидации и в контроллере вызвать валидатор для проверки данных в дто. Если использовать argument resolver/param converter, то вызов валидатора "переедет" в эти классы, а до контроллера "долетит" уже валидная дто со всеми данными

[Daria Motorina]

Sergey Ilichev, про дто и сваггер к сожалению не могу подсказать, я такой вопрос еще не решала)

[Sergey Ilichev]

Daria Motorina, понятно, спасибо за ответы)

[Sergey Ilichev]

oxidmod, спасибо)

[Sergey Ilichev]

tommy-vercetti, ваш вариант кажется интересным, но это надо ваш код в отдельный пакет и с инструкцией, чтобы другие могли пользоваться, а так идея красивая, но в целом себе перенести в существующий проект уже сложно) Но спасибо за идею в целом)

Answer 3

[Дмитрий Гординский]

Помимо уже перечисленного, переданный в публичный метод сервиса набор параметров зачастую продолжает гулять по приватным методам или компонентам сервиса, и делать это проще с одной DTO, чем с пачкой параметров.

Comments

[Sergey Ilichev]

А как по факту решается проблема понимания того, что вообще метод должен получать? Ну допустим смотрит другой разработчик на этот метод, там один параметр, какой-то $someDtoObject. На основе этого вообще можно тот же сваггер построить?

[Дмитрий Гординский]

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

[Sergey Ilichev]

Дмитрий Гординский, ну так обычно они со строгим указанием, например (array $filters, int $offset, int $limit), а DTO предполагает что будет вместо этого просто $someDto с непонятным типом.

[Sergey Ilichev]

Дмитрий Гординский, вот я выше писал пример

Я просто может не так понимаю, но не вижу профита от этого.

Допустим у меня есть метод в сервисе А, который принимает параметры (array $filters, int $offset, int $limit)

Я в сервисе Б создаю массив [$filters, 0, 10] и передаю его курлом в функцию. Все просто.

Предположим, что используется DTO.

Тот же метод в сервисе А, только теперь непонятная сигнатура типа ($someDtoObject)

$requestObject = SomeDtoRequest::makeDtoObject(['filters' => $filters, 'offset' => 0, 'limit' => 10]);
И опять отправляем курлом.

Вопрос - как вообще сервис A будет ругелировать, что это вообще за $someDtoObject, какого он типа? И как разработчик сторонний использующий этот метод поймет что в этом объекте должно быть?

Я себе представляю использование DTO так, что создавать такие объекты нужно для полученного респонса например. То есть получили ответ, завернули его в DTO и дальше используем. Но в реквесте не понятно как это использовать.