эм, детализировать что? ты хочешь реализовать паттер visitor с помощью DIC? а как быть с тем, что контейнер уже скомпилирован? что данные о пользователе за зависимость не особо катят? что именно ты хочешь услышать-то?)

эм, детализировать что? ты хочешь реализовать паттер visitor с помощью DIC? а как быть с тем, что контейнер уже скомпилирован? что данные о пользователе за зависимость не особо катят? что именно ты хочешь услышать-то?)

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

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

а чё пользователю делать в контейнере?

Не пользователь, внутри будет билдер возвращающие VisitorInterface

у этого интерфейса какие методы будут?

Короч зря выдумываю грабли. Просто сейчас из DIC получаю VisitorBuilder и уже на уровне сервиса делаю detect() для получения пользователя. Вот подумал а не стоит ли это сделать в контейнере

ты просто слегка (нет) неверно описываешь что хочешь и что есть)

ты просто слегка (нет) неверно описываешь что хочешь и что есть)

Да, объяснение не самая лучшая моя сторона

а от чего этот билдер зависит?

От реквеста, репозитория + всякие сторонние интерфейсы для детектирования ботов и т.п. На выходе получаю плоский Visitor объект типа DTO

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

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

у меня процесс скармливания зависимостей билдеру происходит в composite root приложения. А так в целом все тоже самое.

сойдёт значит)

Приятно удивлен, что не нашел пакетного обновления данных в MySQL. Вроде как только чрез INSERT INTO .... ON DUPLICATE KEY UPDATE ...

Приятно удивлен, что не нашел пакетного обновления данных в MySQL. Вроде как только чрез INSERT INTO .... ON DUPLICATE KEY UPDATE ...

ты типа хочешь UPDATE разными данными разные ряды?) этого ни у кого нет)

и да только через ON CONFLICT и прочие апсерты

Да, есть юзкэйс, что на странице может быть 10 баннеров (не которые из них могут повторяться). Надо увеличить счетчик просмотров. А так, ясно, просто странно использовать для этого INSERT хоть и с постусловием

Да, есть юзкэйс, что на странице может быть 10 баннеров (не которые из них могут повторяться). Надо увеличить счетчик просмотров. А так, ясно, просто странно использовать для этого INSERT хоть и с постусловием

UPDATE banner_views SET views=views+1 WHERE id IN (1, 2, 3)

UPDATE banner_views SET views=views+1 WHERE id IN (1, 2, 3)

в том то и дело, что может быть не 1 просмотр. а сразу 2 и более для 1 id

поэтому только через INSERT ... UPDATE

в том то и дело, что может быть не 1 просмотр. а сразу 2 и более для 1 id

странная логика

я бы писал это все тупо инсертами и потом разгребал лог.

@fesor, ты писал что в контроллере не допускаешь if'ов. А валидация входящих данных (которыми видимо заполняются нужные DTO) где происходит?

@fesor, ты писал что в контроллере не допускаешь if'ов. А валидация входящих данных (которыми видимо заполняются нужные DTO) где происходит?

я сегодня за фесора: резолверы

Резолверы возвращаются исключения если что-то не так? Можно ссылочку почитать как это выглядит или ключевые слова для гуглинга

это https://symfony.com/doc/current/components/options_resolver.html ???

не совсем

argument resolver

да, если что не так - бросают исключения, симфа потом ловит и отдает страничку с ошибкой

я сегодня за фесора: резолверы

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

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

я говорю о том, как делает фесор)

У меня входящие дто валидирует обычный symfony validator, правила описываются в аннотациях dto

У меня входящие дто валидирует обычный symfony validator, правила описываются в аннотациях dto

если фэйл, то что?

А сам механизм валидации в декораторе над шиной.

точнее, фэйл в контроллере обрабоатываешь?

Если фэйл, то массив с фэйлами будет не пустой

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

Там же в мидлваре

В декораторе тоесть

понял, т.е. на уровне мидлвари ты отдаешь ответ с фэйлом и полями

Ага

А в symfony есть концепт мидлварей? Быстрый гуглинг дает костыльные решения. Может не там ищу..?

нет, в симфони ивенты и листенеры

#Вопрос если кто-то работал с базой текдок, подскажите запрос к базе, как по оригиналтному номеру найти аналоги в базе текдока

А сам механизм валидации в декораторе над шиной.

А что это за шина? Это из симфони или какой-то базовый концепт?

А что это за шина? Это из симфони или какой-то базовый концепт?

Это шаблон проектирования CommandBus. Реализаций масса. Вот тут чуть подробнее о чем это. https://matthiasnoback.nl/2015/01/responsibilities-of-the-command-bus/

Это шаблон проектирования CommandBus. Реализаций масса. Вот тут чуть подробнее о чем это. https://matthiasnoback.nl/2015/01/responsibilities-of-the-command-bus/

Спасибо!

Сергей З. (0) увеличил репутацию Vitaly B (1)

если нет распределёнки, то от шины весьма сомнительная польза. Усложнение на ровном месте без видимого профита

ну и рспределёнка - уже не команд, а мессейдж

если нет распределёнки, то от шины весьма сомнительная польза. Усложнение на ровном месте без видимого профита

О какой распределенке речь?

Ну типа уменьшили связанность

Ну типа уменьшили связанность

ну типа нихуя не уменьшили) только добавили толпу геморроя)

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

ну типа нихуя не уменьшили) только добавили толпу геморроя)

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

ну оно как бы всегда так

приходится платить головабобо

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

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

команд бас никак не мешает бяки делать

давай примеры, поудивляюсь)

public function handle(GetUserDataCommand $command) { } ня_)

public function handle(GetUserDataCommand $command) { } ня_)

ну это уже не про комманд басы, а про мозги)

Ну это же золушка - заглушка!!!!

ну это уже не про комманд басы, а про мозги)

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

Ну это же золушка - заглушка!!!!

э?

э?

ничего не выполняющий хендл, а?

ERROR: S client not available

ничего не выполняющий хендл, а?

название команды смотри

название команды смотри

к слову о басах, да)

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

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

ну и на чтение бас не юзаю, канеш

название команды смотри

Типа ничего не возвращаем, а командуем

Типа ничего не возвращаем, а командуем

типа еще и возвращать там кто-то собирается

название команды смотри

Ну вот так же нельзя, если используешь командбас, то следуешь парадигме CQS

Ну вот так же нельзя, если используешь командбас, то следуешь парадигме CQS

это ты извращенцам скажи

я, кстати, в определенный момент тоже хотел возвращать результат команды даже поддержку этого запилил, но вовремя одумался

это ты извращенцам скажи

А они сами догадаются, когда хэндлер ничего не вернет

А они сами догадаются, когда хэндлер ничего не вернет

от шины зависит)

вроде tactician такое умеет фактически он именно message bus - как и многие штуки от league, он довольно гибкий

public function getUserData(Command $command, Context $context): void { $someUserData = [/** ... */]; $context->publish(new UserDataLoadedEvent($someUserData)); }

ничё не возвращаем)

Огонь)

басы аще никак не мешают делать бяки. Ну вот совсем никак

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

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

А каким образом без шины можно реализовать концепцию middleware? Для валидации, например или для бд транзакций. Декоратором над контроллером?

а где там связь между шинами и мидлварами?

мидлвар для транзакций аще как-то жутко звучит

чую мерзкий запах ларавеля

мидлвар для транзакций аще как-то жутко звучит

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

мб кому-то и удобно, но я бы своим парням за такое руки сломал

мб кому-то и удобно, но я бы своим парням за такое руки сломал

Почему? Не очевидно?

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

а плюсов аще нету

мб кому-то и удобно, но я бы своим парням за такое руки сломал

у тебя все живые, а то часто слышу о членовредительстве ???

у тебя все живые, а то часто слышу о членовредительстве ???

ни единой царапины)

ни единой царапины)

нет тела - нет царапины

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

Ну хз. о каких принципах речь? ACID? В таком случае ничто не противоречит. Следуя логике CQS можно все команды на запись выполнять через шину с поддержкой транзакций.

угу, как скажешь)

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