ответ на твой вопрос - зависит от задачи

Ну так лэйзи не рак, программист - рак)

мне валидация нужна пока запрос в контроллер не пришел

мне валидация нужна пока запрос в контроллер не пришел

какой к черту запрос???

вот для этого и нужен дто с мета инфой для валидации в аннотациях

каким обьектом? создать обьект из пустого места?

Ну я так надеялся что оно в экшене из параметра создаст инстанс и просетит туда все что сможет согласно присутствующим пропертям в объекте.

там вот удобно например именно дто а не какой то массивчик

мне валидация нужна пока запрос в контроллер не пришел

речь идет ТОЛЬКО о респонсах. Научись уже дочитывать сообщения. Я в первом же сообщении об этом написал. Для запросов ясное дело будут объекты.

Ну я так надеялся что оно в экшене из параметра создаст инстанс и просетит туда все что сможет согласно присутствующим пропертям в объекте.

оно добавит тебе параметр в экшн

этого достаточно

есть поговорка такая

делай безобразно но однообразно

ну или хз может не поговорка

ну или хз может быть эта цитата тут не к месту...

кароче если уж юзаешь дто на входе - на выходе тоже дто. вполне себе спокойно можно жить

кароче если уж юзаешь дто на входе - на выходе тоже дто. вполне себе спокойно можно жить

если ты юзаешь строки на входе - юзай их и в бизнес логике

boundaries между слоями не отменяли )

юзай массивы если нравится )

оно добавит тебе параметр в экшн

как то не удобно это всё кучу параметров надергивать, объектом было бы удобнее. Ладно, будем искать.

boundaries между слоями не отменяли )

а если мы разделим между собой задачи "обработки данных" и "формирование представления"?)

потому что они разные

сможем провести границу

и теперь "единообразие" притянуто зауши

т.е. хочешь сказать что передать объект в темплейтер это уже прям нарушение закона

это как "если мы пишем в сущность которая грузится в UoW то и читать должны тоже с испльзование UoW"

т.е. хочешь сказать что передать объект в темплейтер это уже прям нарушение закона

передать сущность - да)

дто жы не сущность

дто и есть чтобы между границами передавать

Подскажите бандл или либу, которая может валидировать JSON по JSON Schema v5?

как то не удобно это всё кучу параметров надергивать, объектом было бы удобнее. Ладно, будем искать.

ParamFether твой обьект

он один

я еще раз повторю - как ты хэндлишь ситуации когда у тебя есть 5 ролей и одна один.... ну например JSON и поля какие-то для каких-то ролей надо скипать

Подскажите бандл или либу, которая может валидировать JSON по JSON Schema v5?

искал, вроде сам не нашёл. Только 4

искал, вроде сам не нашёл. Только 4

@thatside вроде бы находил

кароче если уж юзаешь дто на входе - на выходе тоже дто. вполне себе спокойно можно жить

еще накину - а graphql ты смотрел?)

я еще раз повторю - как ты хэндлишь ситуации когда у тебя есть 5 ролей и одна один.... ну например JSON и поля какие-то для каких-то ролей надо скипать

на выходе или на входе?

opis кажись, я сейчас не у компа

на выходе или на входе?

на выходе

еще накину - а graphql ты смотрел?)

да смотрел но у меня писюн еще не дорос такое реализовать

искал, вроде сам не нашёл. Только 4

выше написал

на выходе

т.е. вопрос про то где зачистить респонз от ненужных данных

у сериалайзера изолирующий слой - массивчики)))

https://github.com/opis/json-schema/

Opis Json Schema is a PHP implementation for json-schema draft-07 and draft-06.

?

т.е. вопрос про то где зачистить респонз от ненужных данных

именно

у тебя будет 5 DTO или 1 DTO?

т.е. вопрос к тому чтобы занулить пару полей в dto против передачи уже чистого "массивчика"

без лишних полей

т.е. вопрос к тому чтобы занулить пару полей в dto против передачи уже чистого "массивчика"

5 DTO или 1 DTO + фабрика?

5 дто и аннотации

пусть сериализер разбирается

ParamFether твой обьект

Ок спасибо. Наверное буду им довольствоваться, но все же жаль что нельзя в кастомный объект просетить (

пусть сериализер разбирается

не понимаю... кто будет выбирать DTO? причем тут сериалайзер или аннотации если у тебя и так 5 DTO

чего не понимаешь

сериализер превращает дто уже в респонз который отдается клиенту. хер его знает это json/xml/array понятия не имею

та можно, лично я сделал свою аннотацию PaginationParams которая лжидает, валидирует filters, sorts, offset, limit и вставляет как параметры в экшн

чего не понимаешь

я бы хотел посмотреть как бы выглядел контроллер в такой ситуации (ну в идеале вообще код)

сериализер превращает дто уже в респонз который отдается клиенту. хер его знает это json/xml/array понятия не имею

ты сказал у тебя на 5 ролей 5 DTO

изи можно сделать чтобы был обьект. но это время и вопрос надо ли оно тебе

зачем сереалайзеру что-то решать?

если есть дто - можно обозначить аннотации чтобы сериализер вырезал поля когда выполняется какое то условие

сериализер превращает дто уже в респонз который отдается клиенту. хер его знает это json/xml/array понятия не имею

а если 2 поля из 10-ти доставать дорого и надо это только админам?

затем чтобы не юзать кругом массивчики

затем чтобы не юзать кругом массивчики

догматическая логика какая-то

а, на 5 ролей 5 дто

не, 1 дто канешно, я думал 5 на разные операции

ERROR: S client not available

окей, все ще - вот у тебя есть 10 полей, из них два доставать дорого по ресурсам (ну так вышло) и надо они только для админов (их мало и там пофигу)

ты предлагаешь доставать все для всех и потом чистить

как поступишь?

лол

так эти поля нужны или не нужны

так эти поля нужны или не нужны

админам нужны - остальным нет, DTO у тебя одна

если у тя код выполняет тяжелые операции независимо от того кто клиент, хотя надо только для админов - дто то тут причем

если у тя код выполняет тяжелые операции независимо от того кто клиент, хотя надо только для админов - дто то тут причем

при том что у меня данные собираются без излишков (особо)

а у тебя с излишками

так тут уже про оптимизацию

у тебя 1 DTO

ты сам выше сказал

и

кто заполняет данными?

кто потом будет решать какой DTO подсовывать?

`if`ы в контроллерах?

ты код покажи

там поспорим )

а так че голову ломать над абстрактной выдуманой ситуацией

если будешь передавать массивчики между слоями - их хуй потом завалидируешь

на каждом шаге

а для дто это можно автоматизировать

вот тебе типичный код когда DTO неудобно if ($user->isAdmin()) { return $dataProvider->dataWithSomeComplexStuff(); // уже вернет тебе `DataWithCOmplexStuffDTO` } elseif ($user->isSomeOtherUser()) { return $dataProvider->dataWithLessStuff(); // уже другой тип DTO }

ну и т.д.

а для дто это можно автоматизировать

я еще не добрался до примеров когда в куче запросов фигурирует какой-нибудь профиль пользователя (часто используемые вложенные структуры) - кто данные туда будет агрегировать?

зачем из метода возвращать два разных типа дто

+ ситуации когда у тебя респонс содержит данные из нескольких контекстов (границы и все такое) и данные надо как-то скомпоновать...

почему бы не вернуть один и тот же

почему бы не вернуть один и тот же

тогда по сути единственная цель твоих DTO - контейнер с данными и перечень возможных полей (вообще без какой-либо возможности валидации)

валидацию будет делать следующий слой, который примет данные

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

валидацию будет делать следующий слой, который примет данные

у него свои правила?