а у него строгий регламент входных данных и исключений

входные данные могут быть как простыми, так и DTO: $creator->create($login, $pass); // or $creator->create(new CredentialsDTO( login: $login, password: new NonEncryptedPasswordDTO($pass), ));

в Апи платформе там както попроще чтоли оно само както сохраняет это всё дело гдето

ну так всё вот это для rapid разработки

ну зависит от тебя, в любом случае у тебя есть какой-то UserSaver или UserDeleter или ещё что

так что нету у меня этого всего

с таким же успехом можно ларку взять)

Вот пример)

дак лучше б ларку, ей-богу оно ни туда ни сюда :)

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

работает и ладно

да а тут всё посложнее, а сроки хотят как будто на ларке

ну и форма в догонку

в моём случае пустая строка недопустима, например

это понятно всё

Ну раз так, тогда ты понял где у тебя ошибки денормализации вылетать должны, а где ошибки валидации) В моём примере 1) "не пустая строка" - это тип данных и кривая форма. 2) А "кривая регулярка" - ошибка сервиса сохранятора.

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

Ну раз так, тогда ты понял где у тебя ошибки денормализации вылетать должны, а где ошибки валидации) В моём примере 1) "не пустая строка" - это тип данных и кривая форма. 2) А "кривая регулярка" - ошибка сервиса сохранятора.

да, понял вроде, спасибо большое!

P.S. Я не ебу ваще как там в апи платформ)))

ну там сохраняторы это стейт процессоры

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

утро вечера мудренее

ты технически не можешь на одном уровне всё это делать

у тебя полюбасу есть какая-то логика сложная, которую в констреинт просто так не запихнуть

*скорее всего

привет! Как валидировать данные перед денормализацией и православно ли это? Дело в том что в процессе денормализации я создаю валью обжекты чтобы сохранить их в БД, и если значение не валидное то мой валью обжект падает.

Если апилплатформа, то не мучаться и делать как там заведено и показано в доке симфы/платформы из коробки и не задаваться архитектурными вопросами, так как это уже всё не архитектурно (rad разработка). Пихаете контрейнты в сущности и не паритесь. Если используете дто - то в дто.

Имхо перебор с кол-вом слоев, ну да ладно) А кто дтошку потом в респонс превращает? Какой то единый ViewEventListener с сериализатором? Или на каждую response дто еще респонсер ?

Если апилплатформа, то не мучаться и делать как там заведено и показано в доке симфы/платформы из коробки и не задаваться архитектурными вопросами, так как это уже всё не архитектурно (rad разработка). Пихаете контрейнты в сущности и не паритесь. Если используете дто - то в дто.

Так так, уже лучше :) А не подскажете ли, как мне с VO поступить. Они создаются при десериализации, а валидация случается после десериализации. А там в VO поля типизированные, надо бы отвалидировать перед этим.

Имхо перебор с кол-вом слоев, ну да ладно) А кто дтошку потом в респонс превращает? Какой то единый ViewEventListener с сериализатором? Или на каждую response дто еще респонсер ?

хотя мб и имеет смысл если хочется заморочиться и потом преобразовывать в разные форматы на лету в зависимости от accept content type 🙄

Так так, уже лучше :) А не подскажете ли, как мне с VO поступить. Они создаются при десериализации, а валидация случается после десериализации. А там в VO поля типизированные, надо бы отвалидировать перед этим.

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

Как же решить такую проблему без ддд и гексагонов

Можно в один слой, бог с ним

Как же решить такую проблему без ддд и гексагонов

Читатнием гитхаба, so и доки)

https://symfonycasts.com/screencast/api-platform/validation

Лучше посмотрите весь каст

Думаю встретите много интересного для решения проблем с апи платформой

https://symfonycasts.com/screencast/api-platform/validation

Смотрел вот сегодня

Не помогло

Ну и подобные штуки гуглить https://github.com/api-platform/core/issues/4250

https://api-platform.com/docs/core/validation/ раздел Collecting Denormalization Errors

https://api-platform.com/docs/core/validation/ раздел Collecting Denormalization Errors

спасибо, не знал, не дочитывал до конца это, включил, падает так же

там да, на конструкторе VО

хз как этот флаг работать должен

наверное как-то должен

Зачем называть Аддер, апдейтер, делетор, етц...? Почему не назвать просто PatternAdd $handler? Где-то видел статейку про то что ваши окончания-or, -er говно! Или в книжке... Уже не помню.

Зачем называть Аддер, апдейтер, делетор, етц...? Почему не назвать просто PatternAdd $handler? Где-то видел статейку про то что ваши окончания-or, -er говно! Или в книжке... Уже не помню.

А вот обратное, а почему нет?

А вот обратное, а почему нет?

Хз, пиндосу видимо неприятно такое читать )

Объективных причин нету

Хз, пиндосу видимо неприятно такое читать )

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

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

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

Хз я особо не слышал. Сервис он и есть сервис. По названию в целом понятно, даже не используя этот стиль у себя.

Опять же сколько людей столько и мнений. Кому нравится так, кому то иначе. Если же нет какого конкретного профита, то субъективщина

Хз я особо не слышал. Сервис он и есть сервис. По названию в целом понятно, даже не используя этот стиль у себя.

Пик1 почему это плохо, Пик 2 альтернативы так себе 😄

Хз я особо не слышал. Сервис он и есть сервис. По названию в целом понятно, даже не используя этот стиль у себя.

Пик1 почему это плохо, Пик 2 альтернативы так себе 😄

Да, когда ты пишешь тупо UserHandler без обозначающей папки или еще чего, то это нихера не понятно. Но у Кирилла как раз пик два, adder. Т.е. понятно для чего

Ну с юзерхандлером согласен, че он там хандлит вопрос вопросов. Чет не предложила мой вариант просто написать UserAdd, как команду. Видимо такое не практикуют вообще )

сука, опять бегать переименовывать всё насвете... да когда уже это кончится?! 🤣🤣🤣

Ну с юзерхандлером согласен, че он там хандлит вопрос вопросов. Чет не предложила мой вариант просто написать UserAdd, как команду. Видимо такое не практикуют вообще )

Да, есть такое что суффиксы тип правктика не очень, тип и интерфейсы не писать и ивенты. Но имхо, с суфиксами банально проще искать по проекту

Тип UserAddCommand а есть какой нить UserAddedEvent

А если без суффиксов, то будет UserAdd и UserAdded, имхо визуально более путанее смотрится без суффиксов и искать по вхождению фразы будет чуть сложнее

С ивентами да

сук еще думать над названиями...

сук еще думать над названиями...

Делать так, как удобно в команде. Если ты один - ну тут уже как тебе кажется профитнее

Сильно субъектиная штука, думаю не стоит замарачиваться как правильно или нет. На скорость проекта не влияет))

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

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

Пока нет в PSR то не будет противоречий)

Есть общие рекомендации. Вон ор, ер плоха, но можно если точно отражает суть. Глаголы плоха, но если команда(конкретное действие) то чеб и нет? Всякие обшие суффиксы типа Sevice тоже плохо.

которые не особо зависят от языка

Есть общие рекомендации. Вон ор, ер плоха, но можно если точно отражает суть. Глаголы плоха, но если команда(конкретное действие) то чеб и нет? Всякие обшие суффиксы типа Sevice тоже плохо.

Плохо, что типо не варазительно. Типа UserService - хер проссышь что это

Если можешь, то лучше во что то переименовать или декомпозировать.

ну вот для юзкейса как выбирать? я хз даже сейчас. писал просто UserAdd не рефлексируя ) но это говно, UserSignup тоже с глаголом. UserRegistration? Ну хз... а если это не юзер а статья? Её не зарегистрируешь :D

получается все тот же адд\аддер, всратый

ну вот для юзкейса как выбирать? я хз даже сейчас. писал просто UserAdd не рефлексируя ) но это говно, UserSignup тоже с глаголом. UserRegistration? Ну хз... а если это не юзер а статья? Её не зарегистрируешь :D

Ну вот я суффикс добавляют, или префикс папкой

UserAddHandler UserAdd/Handler

Не парься, если нет каких то проблем и нравится - забей)

Но мне глагол не очень, но опять же не критикал, ко всему привыкаешь

я перфекционист ебучий, и эта тема щас будет неделю голову греть 😰 и все равно ничего не изменится...

я перфекционист ебучий, и эта тема щас будет неделю голову греть 😰 и все равно ничего не изменится...

скинули вырезку из чистого кода:

скинули вырезку из чистого кода:

а что с Data не так? сук... как по мне это лучше чем дто, хотябы отражает то, что объект с данными