Розуміння того, як працюють фронт-контролер, ядро та середовища разом
Дата оновлення перекладу 2023-08-25
Розуміння того, як працюють фронт-контролер, ядро та середовища разом
Розділ середовища конфігурації пояснював основи того, Symfony використовує середовища для запуску вашого додатку з різними налаштуваннями конфігурації. Цей розділ розповість трохи більше про те, що відбувається, коли ваш додаток самозавантажується. Щоб підключитися до цього процесу, вампотрібно зрозуміти три частини, що працюють разом:
Note
Зазвичай вам не знадобиться визначати ваш власний фронт-контролер або клас
Kernel
, так як Symfony надає розумні реалізації за замовчуванням. Ця
стаття надана для того, щоб пояснити, що відбувається за лаштунками.
Фронт-контролер
Фронт-контролер - це патерн програмування; він є розділом коду, через який проходять всі запити, що обслуговуються додатком.
В Symfony Skeleton цю роль переймає файл 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()
і може також реєструвати нові параметри контейнера та сервіси.
Щоб заповнити ці (невеликі) пробіли, ваш додаток повинен створити підклас ядра
та реалізувати ці методи. Результуючий клас за угодою називається 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 за замовчуванням.