Size: a a a

2020 October 07

SP

Sergey Protko in symfony
и да - этот подход "норм" только для тупого круда, аля лайки.... в целом table gateway будет проще))
источник

k

knopkod4v in symfony
Павел Г.
+ не совсе понятно как я из DI прокину UserID
не надо из DI прокидывать userId, он тебе известен становится в рантайме
источник

SP

Sergey Protko in symfony
опять же - я просто набрасываю что бы может с другого угла на проблему посмотреть)
источник

ПГ

Павел Г. in symfony
knopkod4v
не надо из DI прокидывать userId, он тебе известен становится в рантайме
В примере просто было в контроллере.
источник

SP

Sergey Protko in symfony
тут много чего - репозиторий как фабрика, что бы дискутировать на тему того должны ли имена паттернов быть в именах классов...
источник

k

knopkod4v in symfony
Павел Г.
В примере просто было в контроллере.
это ж пример, а не реальный код
источник

SP

Sergey Protko in symfony
Павел Г.
В примере просто было в контроллере.
я просто для ресурсов основных стараюсь аргумент ресолверы делать что бы форсить проверки доступов всякие.
источник

k

knopkod4v in symfony
Павел Г.
В примере просто было в контроллере.
да и кто сказал, что контроллер нельзя вызывать как функцию
источник

ПГ

Павел Г. in symfony
Sergey Protko
тут много чего - репозиторий как фабрика, что бы дискутировать на тему того должны ли имена паттернов быть в именах классов...
Ну в целом выходит что мы делаем сервис класс, который имеет стейт и потом запуливает команды в репозиторий.
Тут правда немного проблема с атомарностью  возникает, так ак мы уже не флашим.
источник

SP

Sergey Protko in symfony
Павел Г.
Ну в целом выходит что мы делаем сервис класс, который имеет стейт и потом запуливает команды в репозиторий.
Тут правда немного проблема с атомарностью  возникает, так ак мы уже не флашим.
там нет стэйта - айдишка ж не меняется
источник

SP

Sergey Protko in symfony
и класс этот не в контейнере живет - так что все ок
источник

SP

Sergey Protko in symfony
повторюсь - это не призыв так делать - скорее наброс что так можно и это ничем не хуже (а может и лучше) чем ебаться с доктриной. как миниму для подобных кейсов
источник

ПГ

Павел Г. in symfony
Sergey Protko
повторюсь - это не призыв так делать - скорее наброс что так можно и это ничем не хуже (а может и лучше) чем ебаться с доктриной. как миниму для подобных кейсов
Тут скорее вопрос, чем это лучше $likeService->like($postId, UserID) ?
источник

SP

Sergey Protko in symfony
ну и еще есть куча других плюшек в стиле "ты весь функционал лайков сможешь протестить не создавая в тестах реальных юзеров и реальных постов"
источник

SP

Sergey Protko in symfony
Павел Г.
Тут скорее вопрос, чем это лучше $likeService->like($postId, UserID) ?
ничем)
источник

ПГ

Павел Г. in symfony
Выглядит интересно, но интересен профит
источник

SP

Sergey Protko in symfony
в этом случае точно ничем
источник

SP

Sergey Protko in symfony
Павел Г.
Выглядит интересно, но интересен профит
тотальная изоляция данных. посты ничего не знают о лайках а лайки знают о постах только то что есть вообще такие вещи
источник

SP

Sergey Protko in symfony
гипотетически ты можешь лайки реализовать так что они ничего не будут знать что ты лайкаешь
источник

SP

Sergey Protko in symfony
(ларавельщики это называют полиморфными связями, я это называю отсутствием явных связей)
источник