Feature Global registry

🌍 Глобальный реестр

← Возможности · Главная · Сравнение

ContainerRegistry даёт доступ к контейнеру приложения из мест, куда его неудобно прокинуть (helper-функции, legacy-код, фасады). Туториал — Global-registry.

Принцип работы

ContainerRegistry — статический держатель ссылки на «текущий» контейнер приложения. На bootstrap контейнер регистрируется в реестре; затем глобальный код может получить его и достать сервис. Это осознанный escape hatch для интеграции с кодом, не поддерживающим DI.

// bootstrap:
$c = new Container();
// … настройка …
ContainerRegistry::set($c);

// где-то в helper/legacy, куда контейнер не прокинуть:
function logger(): LoggerInterface {
    return ContainerRegistry::get()->get(LoggerInterface::class);
}

Плюсы

• Мост к legacy и глобальным функциям, где внедрить контейнер нельзя.
• Основа для фасад-подобного API (как в Laravel).
• Простой доступ в скриптах/хелперах.

Минусы

• Глобальное состояние — усложняет тестирование и параллелизм; по сути Service Locator.
• Скрывает зависимости: по сигнатуре не видно, что функция лезет в контейнер.

✅ Рекомендуется

• Использовать только на границе с кодом, который нельзя перевести на конструктор-инъекцию (хелперы шаблонов, legacy).
• В тестах — подменять/сбрасывать реестр между кейсами для изоляции.

❌ Антипаттерны

• Дёргать ContainerRegistry::get() внутри доменных сервисов вместо конструктор-инъекции — это классический Service Locator. См. Анти-паттерны.
• Полагаться на глобальный контейнер в многопоточных/долгоживущих сценариях без сброса состояния.

Аналоги в других контейнерах

Контейнер	Аналог
PHP-DI	нет нативного глобального реестра (❌)
Symfony	нет (глобальный доступ намеренно не поощряется) (❌)
Laravel	app() / Facades — центральная часть подхода
Pimple	нет (❌)
Nette	нет (❌)

CloudCastle, Laravel — явный глобальный доступ (используйте осознанно).

См. также: Global-registry (гайд) · Анти-паттерны.