VM
Size: a a a
2020 December 18
SP
Ну я веду к тому, что мы называем "контроллерами" должнф быть как раз конечные сервисы (даже не сервисы, а функции - метод сервиса это прото частный случай). Которые могут быть вызваны по запросу, по событию, из консольной команды. Да вообще пофик откуда - это самостоятельная штука.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е
Ну это в идеале конечно.
Только это не отменяет того факта что контроллер эти проверки должен делегировать кому-то.
SP
Как и "хэндлеры". Вопрос "можно ли if-ми обмазываться" привязан к количеству зависемостей
МФ
Volodymyr Melko
но ведь этот пагинатор искаропки расчитан на работу с орм, разве нет? =)
это повод пользоваться ORM? 🙂
МФ
Допустим 10 элементов, у каждого 10 связей. Это 100 строк из БД. Пагинатор посчитвает пагинацию от 100 строк а не от 10 . Ну и + надо еще как то это сложить потом в масив:
items[
item: {relations[]},
item: {relations[]},
item: {relations[]},
]
я пользуясь возможностями Postgres для твиг-шаблона просто в JSON агрегирую данные связанной сущности
ПГ
я пользуясь возможностями Postgres для твиг-шаблона просто в JSON агрегирую данные связанной сущности
Да, спасибо. Этот момент знаю, удобно, правда херами покрыли в группе мускула :) И он не сработает если 2 связи
МФ
и все, нет расплодившегося числа записей
МФ
Да, спасибо. Этот момент знаю, удобно, правда херами покрыли в группе мускула :) И он не сработает если 2 связи
2 в глубину или просто 2 у записи?
МФ
а вообще если по канону — для read надо проекцию сделать уже в нужном формате и будет все удобно
МФ
для меня это ту мач правда
ПГ
2 в глубину или просто 2 у записи?
И так и так. В глубину вроде группировка не работает вложенная - чисто запорс падает, а просто 2 вроде как тоже - не получится создать два concat join поля - будут лишние данные.
ПГ
а вообще если по канону — для read надо проекцию сделать уже в нужном формате и будет все удобно
Как это сделать с двумя релейшенами? не совсем представляю
МФ
И так и так. В глубину вроде группировка не работает вложенная - чисто запорс падает, а просто 2 вроде как тоже - не получится создать два concat join поля - будут лишние данные.
что за вложенная группировка?
VM
это повод пользоваться ORM? 🙂
зачем тогда юзать пагинатор для того, что можно сделать самому? просто лимит оффсет вкинуть какбы совсем не проблема
МФ
SQL вам в помощь крч 🙂 в этом же и мощь...
если сложные выборки — ну сделайте свой пагинатор
если сложные выборки — ну сделайте свой пагинатор
МФ
зачем комбайн прикручивать к чистке картошки
МФ
его делать то... тем более шатать под него все способы работы с выборками, имея мощный SQL — странноват
ПГ
что за вложенная группировка?
select json_group_concat(json_concat( тут результат запроса с group by и jsob_concat что бы сделать в глубину тоже самое')) from t group by id