Понимание того, как работают фронт-контроллер, ядро и окружения вместе
Дата обновления перевода 2023-08-25
Понимание того, как работают фронт-контроллер, ядро и окружения вместе
Раздел окружения конфигурации объяснял основы того, как Symfony использует окружения для запуска вашего приложения с разными настройками конфигурации. Этот раздел расскажет немного больше о том, что случается, когда ваше приложение самозагружается. Чтобы подключиться к этому процессу, вам нужно понять три части, работающие вместе:
Note
Обычно вам не понадобится определять ваш собственный фронт контроллер
или класс Kernel
, так как Symfony предоставляет благоразумные
реализации по умолчанию. Эта статья предоставлена для того, чтобы объяснить,
что происходит за кулисами.
Фронт-контроллер
Фронт-контроллер - это паттерн программирования; он является разделом кода, через который проходят все запросы, обслуживаемые приложением.
В Скелетоне Symfony эту роль перенимает файл index.php
в каталоге
public/
. Этот PHP-скрипт выполняется самым первым при обработке запроса.
Главной целью фронт контроллера является создание экземпляра Kernel
(больше об этом через секунду) для обработки запроса и возвращения результирующего
ответа в браузер.
Так как маршрут каждого запроса проложен через него, фронт контроллер может быть использован для выполнения глобальной инициализации до установки ядра или декорирования его с помощью дополнительных функций. Примеры включают в себ:
- Конфигурацию автозагрузчика или добавление дополнительных механизмов автозагрузки;
- Добавление HTTP-уровня кеширования, обернув ядро экземпляром HttpCache ;
- Подключение компонента Debug.
Вы можете выбрать используемый фронт-контроллер, добавив его в URL:
1
http://localhost/index.php/some/path/...
Как вы можете увидеть, этот URL содержит PHP-скрипт, который будет использован
как фронт-контроллер. Вы можете использовать это, чтобы легко переключаться
на пользовательский фронт-контроллер, расположенный в каталоге public/
.
See also
Вам почти никогда не стоит отображать фронт-контроллер в URL. Это достигается путём конфигурирования веб-сервера, как показано в Конфигурация веб-сервера.
Технически, скрипт bin/console
, используемый при запуске Symfony в командной строке,
- это тоже фронт контроллер, только используемый не для сети, а для запросов командной
строки.
Класс Kernel
Класс Kernel - это ядро Symfony. Он отвечает за пакеты, используемые вашим приложением, и предоставляет им конфигурацию приложения. Он создаёт сервис-контейнер до обслуживания запросов в своём методе handle().
Ядро, используемое в приложениях Symfony расширяется из Kernel
и использует MicroKernelTrait.
Класс Kernel
оставляет некоторые методы из KernelInterface
нереализованными, а MicroKernelTrait
определяет несколько абстрактных методов,
так что вы должны реализовать их все:
- registerBundles()
- Должен вернуть массив всех необходимых для запуска приложения пакетов.
- configureRoutes()
- Добавляет индивидуальные маршруты или коллекции маршрутов в приложение (например, загрузку маршрутов, определённых в некотором файле конфигурации).
- configureContainer()
-
Хагружает конфигурацию приложения из файлов конфигурации или используя метод
loadFromExtension()
и может также регистрировать новые параметры контейнера и сервисы.
Чтобы заполнить эти (небольшие) пробелы, ваше приложение должно создать
подкласс Kernel и реализовать эти методы. Результирующий класс по договёрности
называется AppKernel
.
Этот класс использует имя окружения, которое передаётся методу ядра
constructor и которое
доступно через getEnvironment(), чтобы
решить, какие пакеты создавать. Логика для этого находится в registerBundles()
.
Вы, конечно же, вольны создавать ваши собственные альтернативные или дополнительные
варианты Kernel
. Всё, что вам нужно - это адаптировать (или добавить новый)
ваш фронт контроллер, чтобы воспользоваться новым ядром.
Note
Имя и местоположение Kernel
не фиксированы. При добавлении
нескольких ядер в одно приложение,
может иметь смысл добавить дополнительные подкаталоги, например, app/admin/AdminKernel.php
и app/api/ApiKernel.php
. Имеет значение только то, чтобы ваш фронт-контроллер мог создать
экземпляр правильного ядра.
Note
Kernel
можно использовать для большего, например, для
переопределения структуры каталога по умолчанию.
Но высока вероятность того, что вам не понадобится изменять такие вещи
на лету, имея несколько реализаций Kernel
.
Режим отладки
Второй аргумент конструктора Kernel
указывает, должно ли приложение работать
в "режиме отладки". Независимо от окружения конфигурации ,
приложение Symfony может быть запущено в режиме отладки, установленном как true
или false
.
Это влияет на многие вещи в приложении, такие как отражение трассировки стеков
на страницах ошибок, или динамическое повторное построение файлов кеширования
по каждому запросу. Хоят это не обязательно, режим отладки обычно установлен как
true
для окружений dev
и test
, и как false
для окружения prod
.
Схоже с конфигурацией окружения , вы также можете включать/отключать режим отладки, используя файл .env :
1 2 3
# .env
# установить как 1, чтобы включить режим отладки
APP_DEBUG=0
Это значение можно переопределить для команд, передав значение APP_DEBUG
перед их выполнением:
1 2 3 4 5
# Использовать режим отладки, определенный в файле .env
$ php bin/console command_name
# Игнорировать файл .env, и включить режим отладки для этой команды
$ APP_DEBUG=1 php bin/console command_name
Внутренне, значение режима отладки становится параметром kernel.debug
,
используемым внутри сервис-контейнера. Если вы
посмотрите внутрь файла конфигурации приложения, вы увидите использованный
параметр, к пример, чтобы включить режим отладки Twig:
1 2 3
# config/packages/twig.yaml
twig:
debug: '%kernel.debug%'
Окружения
Как было отмечено только что, Kernel
должен реализовать другой метод -
configureContainer().
Этот метод отвечает за загрузку конфигурации приложения из правильного
окружения.
Окружения подробно описывались в предыдущей статье,
и вы наверное помните, что Symfony по умолчанию использует три: dev
,
prod
и test
.
Технически, эти имена - не более, чем строки, переданные из фронт контроллера
в конструктор Kernel
. Это имя может потом быть использовано в методе
configureContainer()
, чтобы решить, какие файлы конфигурации стоит загружать.
Класс Symfony Kernel
по умолчанию реализует этот метод загружая вначале файлы
конфигурации, найденные в config/packages/*
, а потом файлы, найденные в
config/packages/ENVIRONMENT_NAME/
. Вы, конечно же, вольны реализовывать
этот метод по-другому, если вам нужен более утончённый способ загрузки вашей конфигурации.
Окружения и каталог кеша
Symfony использует преимущества кеширования многими способами: конфигурация приложения, конфигурация маршрутизации, шаблоны Twig и многое другое кешируется в PHP-объекты, хранящиеся в фалах в файловой системе.
По умолчанию, эти кешированные файлы в основном хранятся в каталоге var/cache/
.
Однако, каждое окружение кеширует собственный набор файлов:
1 2 3 4 5 6
your-project/
├─ var/
│ ├─ cache/
│ │ ├─ dev/ # каталог кеша для окружения *dev*
│ │ └─ prod/ # каталог кеша для окружения *prod*
│ ├─ ...
Иногда при отладке может быть полезно исследовать кешированный файл, чтобы
понять, как что-то работает. Делая это, не забудьте посмотреть в каталоге
окружения, которое вы используете (чаще всего dev/
при разработке и
отладке). И хотя могут быть различия, каталог var/cache/dev/
включает в
себя следующее:
srcApp_KernelDevDebugContainer.php
- Кешированный "сервис-контейнер", который представляет собой кешированную конфигурацию приложения.
url_generating_routes.php
- Кешированная конфигурация маршрутизации, используемая при создании URL.
url_matching_routes.php
- Кешированная конфигурация, используемая для сопоставления маршрутов - смотрите здесь, чтобы увидеть скомпилированную логику регулярных выражений, используемую для сопоставления входящих URL с разными маршрутами.
twig/
- Этот каталог содержит все кешированные шаблоны Twig.
Note
Вы можете изменить местоположение и имя каталога кеша. Чтобы узнать больше, прочтите статью Как переопределить стуктуру каталогов Symfony по умолчанию.