Понимание того, как работают вместе фронт контроллер, ядро и окружения

Понимание того, как работают вместе фронт контроллер, ядро и окружения

Раздел How to Master and Create new Environments объяснял основы того, как Symfony использует окружения для запуска вашего приложения с разными настройками конфигурации. Этот раздел расскажет немного больше о том, что случается, когда ваше приложение самозагружается. Чтобы подключиться к этому процессу, вам нужно понять три части, работающие вместе:

Note

Обычно вам не понадобится определять ваш собственный фронт контроллер или класс AppKernel, так как Стандартная версия Symfony предоставляет благоразумные реализации по умолчанию.

Этот раздел документации предоставлен для того, чтобы объяснить, что происходит за кулисами.

Фронт контроллер

Фронт контроллер - это широкоизвестная схема; он является разделом кода, через который проходят все запросы, обслуживаемые приложением.

В `Стандартной версии Symfony`_ эту роль перенимают файлы app.php и app_dev.php в каталоге web/. Эти PHP-скрипты выполняются самыми первыми при обработке запроса.

Главной целью фронт контроллера является создание экземпляра AppKernel (больше об этом через секунду) для обработки запроса и возвращения результирующего ответа в браузер.

Так как маршрут каждого запроса проложен через него, фронт контроллер может быть использован для выполнения глобальной инициализации до установки ядра или декорирования его с помощью дополнительных функций. Примеры включают в себ:

  • Конфигурацию автозагрузчика или добавление дополнительных механизмов автозагрузки;
  • Добавление HTTP-уровня кеширования, обернув ядро экземпляром AppCache;
  • Подключение (или пропуск) ClassCache;
  • Подключение Компонента Отладки.

Фронт контроллер может быть выбран, путём запроса URL вроде:

1
http://localhost/app_dev.php/some/path/...

Как вы видите, этот URL содержит PHP-скрипт для использования в качестве фронт контроллера. Вы можете использовать его для того, чтобы с лёгкостью менять фронт контроллер или использовать заказной, поместив его в каталог web/ (например, app_cache.php).

При использовании Apache и RewriteRule, поставляемого в Стандартной версии Symfony, вы можете опустить имя файла из URL, и RewriteRule использует app.php, как имя по умолчанию.

Note

Почти каждый второй веб-сервер должен мочь достигнуть поведения, схожего с описанным выше поведением RewriteRule. Проверьте документацию вашего сервера или смотрите Configuring a Web Server.

Note

Убедитесь в том, что вы хорошо защитили ваши фронт контроллеры от неавторизованного доступа. Например, вы не хотите сделать окружение отладки доступным для случайных пользователей в вашем окружении производства.

Формально, скрипт bin/console, используемый при запуске Symfony в командной строке, - это тоже фронт контроллер, только используемый не для сети, а для запросов командной строки.

Класс Kernel

Класс Kernel - это ядро Symfony. Он отвечает за установку всех пакетов, из которых состоит ваше приложение, и предоставляет их конфигурацию приложения. Он создаёт сервис-контейнер до обслуживания запросов в своём методе handle().

В классе KernelInterface объявлено два метода, которые не реализуются в Kernel, и поэтому служат в качестве шаблонных методов:

registerBundles()
Должен вернуть массив всех необходимых для запуска приложения пакетов.
registerContainerConfiguration()
Загружает конфигурацию приложения.

Чтобы заполнить эти (небольшие) пробелы, ваше приложение должно создать подкласс Kernel и реализовать эти методы. Результирующий класс по договёрности называется AppKernel.

Опять же, Стандартная версия Symfony предоставляет AppKernel в каталоге app/. Этот класс использует имя окружения, которое передаётся методу ядра constructor и которое доступно через getEnvironment(), чтобы решить, какие пакеты создавать. Логика для этого находится в registerBundles() - методе, предназначенном для ваших расширений при доабвлении пакетов в ваше приложение.

Вы, конечно же, вольны создавать ваши собственные альтернативные или дополнительные варианты AppKernel. Всё, что вам нужно - это адаптировать (или добавить новый) ваш фронт контроллер, чтобы воспользоваться новым ядром.

Note

Имя и местоположение AppKernel не фиксированы. При добавлении нескольких ядер в одно приложение, может иметь смысл добавить дополнительные подкатегории, например, app/admin/AdminKernel.php и app/api/ApiKernel.php. Имеет значение только то, чтоб ваш фронт контроллер мог создать экземпляр правильного ядра.

Наличие разных AppKernels может быть полезным для того, чтобы разные фронт контроллеры могли запускать части вашего приложения независимо друг от друга (например, пользовательский интерфейс админа, пользовательский интерфейс фронтенда и миграции БД).

Note

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

Окружения

Как было отмечено только что, AppKernel должен реализовать другой метод - registerContainerConfiguration(). Этот метод отвечает за загрузку конфигурации приложения из правильного окружения.

Окружения подробно описывались в предыдущей статье, и вы наверное помните, что Стандартная версия Symfony поставляется с тремя - dev, prod и test.

По факту, эти имена - не более, чем строки, переданные из фронт контроллера в конструктор AppKernel. Это имя может потом быть использовано в методе registerContainerConfiguration(), чтобы решить, какие файлы конфигурации стоит загружать.

Класс AppKernel Стандартной версии Symfony реализует этот метод просто загружая файл app/config/config_*environment*.yml. Вы, конечно же, вольны реализовывать этот метод по-другому, если вам нужен более утончённый способ загрузки вашей конфигурации.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.