А вы не в курсе, можно ли где-то подсмотреть такую архитектуру? Может где видели в доступе, например, в блоге или еще где? Просто по описанию сложно представить реализацию, иерархию сущностей, что куда для чего и от кого)
tommy-vercetti, ваш вариант кажется интересным, но это надо ваш код в отдельный пакет и с инструкцией, чтобы другие могли пользоваться, а так идея красивая, но в целом себе перенести в существующий проект уже сложно) Но спасибо за идею в целом)
Я просто может не так понимаю, но не вижу профита от этого.
Допустим у меня есть метод в сервисе А, который принимает параметры (array $filters, int $offset, int $limit)
Я в сервисе Б создаю массив [$filters, 0, 10] и передаю его курлом в функцию. Все просто.
Предположим, что используется DTO.
Тот же метод в сервисе А, только теперь непонятная сигнатура типа ($someDtoObject)
$requestObject = SomeDtoRequest::makeDtoObject(['filters' => $filters, 'offset' => 0, 'limit' => 10]);
И опять отправляем курлом.
Вопрос - как вообще сервис A будет ругелировать, что это вообще за $someDtoObject, какого он типа? И как разработчик сторонний использующий этот метод поймет что в этом объекте должно быть?
Я себе представляю использование DTO так, что создавать такие объекты нужно для полученного респонса например. То есть получили ответ, завернули его в DTO и дальше используем. Но в реквесте не понятно как это использовать.
Дмитрий Гординский, ну так обычно они со строгим указанием, например (array $filters, int $offset, int $limit), а DTO предполагает что будет вместо этого просто $someDto с непонятным типом.
Я просто может не так понимаю, но не вижу профита от этого.
Допустим у меня есть метод в сервисе А, который принимает параметры (array $filters, int $offset, int $limit)
Я в сервисе Б создаю массив [$filters, 0, 10] и передаю его курлом в функцию. Все просто.
Предположим, что используется DTO.
Тот же метод в сервисе А, только теперь непонятная сигнатура типа ($someDtoObject)
$requestObject = SomeDtoRequest::makeDtoObject(['filters' => $filters, 'offset' => 0, 'limit' => 10]);
И опять отправляем курлом.
Вопрос - как вообще сервис A будет ругелировать, что это вообще за $someDtoObject, какого он типа? И как разработчик сторонний использующий этот метод поймет что в этом объекте должно быть?
Я себе представляю использование DTO так, что создавать такие объекты нужно для полученного респонса например. То есть получили ответ, завернули его в DTO и дальше используем. Но в реквесте не понятно как это использовать.
И еще все-таки вопросик - как по факту решается проблема понимания того, что вообще метод должен получать? Ну допустим смотрит другой разработчик на этот метод, там один параметр, какой-то $someDtoObject. На основе этого вообще можно тот же сваггер построить?
А как по факту решается проблема понимания того, что вообще метод должен получать? Ну допустим смотрит другой разработчик на этот метод, там один параметр, какой-то $someDtoObject. На основе этого вообще можно тот же сваггер построить?
А вы говорите, что в DTO может быть логика типа валидации? Я думал (читал), что в DTO максимум может быть валидация типа параметров при создании объекта. Например в php 7.4 это делается за счет указания типа свойства класса, а в версиях ниже кастомно, например на основе php доков. Или там может быть другая логика по мимо этого как в фабрике?
А в симфони это происходит автоматически? То есть приходит запрос в метод api и уже на основе этого формируется заданный как уточнение типа у аргумента функции DTO объект или как-то по другому? Если так, то значит там все api функции для работы такого механизма тоже должны иметь один параметр SomeDto $dto?
ThunderCat, А можете хотя бы примерно описать как бы вы реализовали например такой метод?
Просто я не особо понимаю, что тут в try тогда должно быть, чтобы в catch отдавать ошибку. Или вы имеете ввиду вынести все эти проверки в отдельный метод, типа checkParams или что-то такое и там кидать exception, а ловить его в методе cancelSubscription и возвращать json с ошибкой типа такого ['error' => $e->getMessage(), 'code' => $e->getCode()]? То есть ловить его можно, но бросать в api методе throw SomeException нет смысла так как его уже никто не поймает?
ThunderCat, А можно еще вопросик? А вообще есть ли смысл в api бросать какие либо эксцепшены? Ведь они по сути никак не будут дальше обрабатываться. Например, кинут эксцепшен throw в методе контроллера api и что, если api дергается с другого сервера, просто будет 500 ошибка без указания причины. Поэтому нужно наверное в таких ситуациях именно возвращать json с ошибкой?
А вот в коде приведенном выше, как вообще правильней обрабатывать такие ситуации? Я понимаю, что это вопрос может и вкуса, но вдруг есть какие-то общепринятые способы? Или норм? Типа проверил что нет в посте нужных данных и отправил в ответе ошибку? Или нужно делать кастомные эксцепшены для обработки таких ситуаций С одной стороны вроде выглядит норм, смущает эта куча if с проверкой разных параметров. Спасибо, что ответили.
А если мы говорим, о том, что это наше API, то есть внутри микросервисной архитектуры? Я просто хочу понять, есть ли какие-то на эту тему практики хорошие? Может по опыту встречались, например в крупных компаниях. Еще раз спасибо.
То есть по факту вариант где возвращается массив типа ['result' => 'error', 'message' => 'Guid required', 'code' => 400] это нормально или все же тут правильней использовать Exception? Если тут выкинется, в методе контроллера эксцепшин, то клиенту от этого по сути ничего не будет, то есть на клиенте то, как вы правильно сказали, вообще об эксцепшине ничего не известно. Значит по факту это нормально отправлять клиенту такой массив и чтобы он уже там допустим проверял если есть в нем error, то делать одно, если нет, то другое. Или есть более правильный подход? Спасибо, что ответили.
