Нужен ли контроллер? сейчас пишу фронтенд для некой системы роутер матчит урл и направляет все в несколько контроллеровfunction indexAction( $data ) { switch() { case 1: return $this->render( [ "article" => [..], "events" => [ ..] ] ); case 2: return $this->render( [ "article" => [..], "related_articles" => [ ..] ] ); case 3: return $this->render( [ "folder" => [..], "child_articles" => [ ..] ] ); } } ессно в проекте не switch а куча проверок, определение типа контента, определение конфигурации и т д Т.е это анализ реквеста и извлечении данных ( это не просто Post как во всех гайдах по фрейворкам, в зависимости от запроса, конфига и еще нескольких факторов которые могут появится позже, извлекается article и events или articles и related_articles, кроме извлечения данные могут агрегироватся и т д ) как это сделать по уму? у меня крутится в голове мысль направить все запросы в некий сервис который будет делать этот анализ и возвращать обьекты; - simplePage - twoColumnArticlePage - twoColumnActiclePageWithEvents - gridArticlePage т.е return $twoColumnActiclePageWithEvents->render(); все эти классы наследуются от базового в который запихнуть twig PS. это часть приложения будет только отображать контент. никаких других routes дергаюших контроллеры не будет
Как вы правильно заметили, направление всех запросов в некий сервис, который будет осуществлять анализ запросов и возвращать объекты соответствующих страниц, может быть хорошим подходом для организации вашего фронтенда.
Создание различных классов для разных типов страниц (например, SimplePage, TwoColumnArticlePage, GridArticlePage и т.д.), которые будут отображать контент в зависимости от запроса, конфигурации и других факторов, может упростить управление вашим кодом и сделать его более поддерживаемым.
Каждый из этих классов может иметь метод render(), который будет отображать соответствующую страницу с помощью Twig или другого шаблонизатора. Вы также можете использовать наследование для повторяющейся логики между различными типами страниц.
Такой подход позволит вам изолировать логику отображения контента от остальных частей вашего приложения и упростит добавление новых типов страниц в будущем.
Как вы правильно заметили, направление всех запросов в некий сервис, который будет осуществлять анализ запросов и возвращать объекты соответствующих страниц, может быть хорошим подходом для организации вашего фронтенда.
Создание различных классов для разных типов страниц (например, SimplePage, TwoColumnArticlePage, GridArticlePage и т.д.), которые будут отображать контент в зависимости от запроса, конфигурации и других факторов, может упростить управление вашим кодом и сделать его более поддерживаемым.
Каждый из этих классов может иметь метод render(), который будет отображать соответствующую страницу с помощью Twig или другого шаблонизатора. Вы также можете использовать наследование для повторяющейся логики между различными типами страниц.
Такой подход позволит вам изолировать логику отображения контента от остальных частей вашего приложения и упростит добавление новых типов страниц в будущем.