DA
Size: a a a
2020 December 18
в
🖤
SP
Контроллеры, которые просто перекладывают запросы в сервисы в симфе нафик не нужны. Тут достаточно мощный фронтконтроллер, который позволяет обращаться напрямик к сервисам.
Роутинг + аргумент резолвер и вуаля, половина гетовых контроллеров превращается в метод репы. Остальное в другие сервисы. А контроллеры как точки входа становятся просто бесполезными
Роутинг + аргумент резолвер и вуаля, половина гетовых контроллеров превращается в метод репы. Остальное в другие сервисы. А контроллеры как точки входа становятся просто бесполезными
Я именно это и говорю. Но логики в контроллерах быть не должно. Не потому что "контроллер" а потому что много зависимостей. Логика должна быть там где зависимости минимизированы (whole value это ещё называется)
AB
Sergey
Шторм сломался в последней версии, таблицы в базах не открыть иногда, классы не находит, при поиске по проекту строки некоторые игнорит. Сказка.
Ко всему этому могу добавить совсем неприятную штуку: при работе с несколькими проектами, открывая очередной иногда открывает в нем файлы другого проекта. Эта вообще злая тема очень..
АЯ
Я именно это и говорю. Но логики в контроллерах быть не должно. Не потому что "контроллер" а потому что много зависимостей. Логика должна быть там где зависимости минимизированы (whole value это ещё называется)
Ну я веду к тому, что мы называем "контроллерами" должнф быть как раз конечные сервисы (даже не сервисы, а функции - метод сервиса это прото частный случай). Которые могут быть вызваны по запросу, по событию, из консольной команды. Да вообще пофик откуда - это самостоятельная штука.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
МФ
Ну я веду к тому, что мы называем "контроллерами" должнф быть как раз конечные сервисы (даже не сервисы, а функции - метод сервиса это прото частный случай). Которые могут быть вызваны по запросу, по событию, из консольной команды. Да вообще пофик откуда - это самостоятельная штука.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
Это просто миграция названий...
Вы делаете одно и другое и суммарно получается то, что и делаете... с др названиями
Теперь хэндлер называется контроллером, и из cli команды вы его дёргать собираетесь... что сейчас люди и делают с хэндлером.
Контроллер теперь что-то другое, по факту тоже самое, с др названием...
Не совсем понятно зачем минрировать термины и все делать как было, ну видимо вам виднее
Вы делаете одно и другое и суммарно получается то, что и делаете... с др названиями
Теперь хэндлер называется контроллером, и из cli команды вы его дёргать собираетесь... что сейчас люди и делают с хэндлером.
Контроллер теперь что-то другое, по факту тоже самое, с др названием...
Не совсем понятно зачем минрировать термины и все делать как было, ну видимо вам виднее
АЯ
Это просто миграция названий...
Вы делаете одно и другое и суммарно получается то, что и делаете... с др названиями
Теперь хэндлер называется контроллером, и из cli команды вы его дёргать собираетесь... что сейчас люди и делают с хэндлером.
Контроллер теперь что-то другое, по факту тоже самое, с др названием...
Не совсем понятно зачем минрировать термины и все делать как было, ну видимо вам виднее
Вы делаете одно и другое и суммарно получается то, что и делаете... с др названиями
Теперь хэндлер называется контроллером, и из cli команды вы его дёргать собираетесь... что сейчас люди и делают с хэндлером.
Контроллер теперь что-то другое, по факту тоже самое, с др названием...
Не совсем понятно зачем минрировать термины и все делать как было, ну видимо вам виднее
Это отказ от "контроллеров" как просто передастов запросов в хендлеры.
АЯ
Ну ок.
МФ
Это отказ от "контроллеров" как просто передастов запросов в хендлеры.
Откажетесь, но на фронт-контроллере все равно абстракцию наворачивать... как не назвать, но реквест для роута надо переварить
МФ
То есть предлагаете сделать «иначе», но это изменение будет не принципиальным
АЯ
Не хотите - не делайте. Я ж не заставляю. Можете даже по старинке на каждый роут свой пхп файл писать и не париться с абстракциями
I
Ну я веду к тому, что мы называем "контроллерами" должнф быть как раз конечные сервисы (даже не сервисы, а функции - метод сервиса это прото частный случай). Которые могут быть вызваны по запросу, по событию, из консольной команды. Да вообще пофик откуда - это самостоятельная штука.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
Чет фигня тогда получится. Один большой класс с кучей аннотаций
АЯ
Ivan
Чет фигня тогда получится. Один большой класс с кучей аннотаций
Эээ, нет, не правильно вы меня поняли
ПГ
Приветствую. Нубский вопрос )
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
VM
Приветствую. Нубский вопрос )
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
не по сабжу, но зачем юзать сторонние пагинаторы? Это прямо какая-то сложная штука, писать самому которую сильно сложней и дольше?
СВ
Приветствую. Нубский вопрос )
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
В проекте кнп пагинатор, для него есть грубо говоря форматер для response. Не хотелось бы от этого уходить, т.е продолжать работать с пагинатором как про всему проекту.
Есть read запрос, там связи one-to-many. Запрос через коннекшн. Через пагинатор это не провернуть.
Как лучше поступить?
1) Прям в лоб, делаем запрос без релейшенов создаем пагинатор через paginationInterface->paginate(). Потом делаем еще запрос но уже с релейшенами, форматируем результат, подсовываем в items пагинатор
2) Создаем нативно пагинатор и заполняем его. Меньше запросов, но используется пагинатор КНП (ну или свой написать под интерфейс?).
3) Более правильное решение?
ПГ
Volodymyr Melko
не по сабжу, но зачем юзать сторонние пагинаторы? Это прямо какая-то сложная штука, писать самому которую сильно сложней и дольше?
1) Так уже было сделано до меня. стиль хотелось бы один.
2) В принципе удобно. Создал qb без учета пагинации скормил пагинатору. Он вернул объект в котором результут запроса + данные по пагинации. Не надо самом у писать отдельно запрос на количество сттраниц.
2) В принципе удобно. Создал qb без учета пагинации скормил пагинатору. Он вернул объект в котором результут запроса + данные по пагинации. Не надо самом у писать отдельно запрос на количество сттраниц.