Рабочий процесс построения контейнера

Дата обновления перевода 2021-12-25

Рабочий процесс построения контейнера

Расположение файлов и классов, связанных с компонентом Dependency Injection зависит от приложения, библиотеки или фреймворка, в котором вы хотите использовать контейнер. Если вы рассмотрите то, как построен и сконфигурирован контейнер в комплексном фреймворке Symfony, то вы увидите, как это всё взаимосвязано, независимо от того, используете вы комплексный фреймворк или планируете использовать сервис-контейнер в другом приложении.

Комплексный фреймворк использует компонент HttpKernel для управления загрузкой конфигурации сервис-контейнера из приложения и пакетов, а также обрабатывает компиляцию и кеширование. Даже если вы не используете HttpKernel, то это должно дать вам понимание одного из способов организации конфигурации в модульном приложении.

Работа с кешированным контейнером

До того, как начать построение, ядро проверяет, существует ли кешированная версия контейнера. Ядро имеет настройку отладки, и если она "false", то используется кешированная версия, если она существует. Если отладка "true", то ядро проверяет актуальность конфигурации, и если всё хорошо, то используется кешированная версия контейнера. Если же нет, то контейнер строится из конфигурации на уровне приложения и конфигурации расширений пакета.

Прочтите Сброс конфигурации для производительности , чтобы узнать больше.

Конфигурация на уровне приложения

Конфигурация на уровне приложения загружается из каталога config. Загружается множество файлов, которые потом объединяются при обработке расширений. Это позволяет использовать разные конфигурации для разных окружений, к примеру, dev, prod.

Эти файлы содержат параметры и сервисы, которые загружаются напрямую в контейнер на основании Настройки контейнера с файлами конфигурции . Они также содержат конфигурацию, которая обрабатывается расширениями на основании Управления конфигурацией с расширениями . Это считается пакетной конфигурацией, так как каждый пакет содержит класс Extension.

Конфигурация на уровне пакетов с расширениями

По соглашеию, каждый пакет содержит класс Extension, который находится в каталоге пакета DependencyInjection. Они регистрируются в ContainerBuilder при загрузке ядра. Когда компилируется ContainerBuilder, конфигурация на уровне приложения, связнная с расширением пакета, передаётся расширению, которое обычно загружает собственный(е) файл(ы) конфигурации, обычно из каталога пакета Resources/config. Конфигурация на уровне приложения обычно обрабатывается объектом Configuration и также хранится в каталоге пакета DependencyInjection.

Передачи Compiler для позволения взаимодействия между пакетами

Передачи Compiler используются для позволения взаимодействия между разными пакетами, так как они не могут повлиять на конфигурацию друг друга в существующих классах. Основными способами применения являются обработка тегированных сервисов, позволение пакетам регистрировать сервисы, которые подхватят другие пакеты, вроде логгеров Monolog, расширений Twig, сборщиков данных для Web Profiler. Передачи Compiler обычно размешаются в каталоге пакета DependencyInjection/Compiler.

Компиляция и кеширование

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