Внедрение зависимостей в Joomla 4

Информация о материале: Родительская категория: CMS — движки сайтов; Категория: Joomla 4

Введение

Joomla 4 вводит в использование контейнеры для инъекций зависимостей (Dependency Injection Containers — DIC). Цель этой статьи-объяснить, почему мы их представляем и как их использовать в Joomla.

DIC уже давно существуют в экосистеме PHP для поддержки целей внедрения зависимостей. Например, Symfony представила эту концепцию в 2009 году.

Существует множество причин, по которым сейчас самое подходящее время ввести их в Joomla 4:

Тестирование — одной из тем Joomla 3 были выпуски с ошибками. Нам нужно иметь возможность проще тестировать классы и компоненты. Внедрение зависимостей позволяет значительно упростить внедрение фиктивных классов, что, надеюсь, позволит нам уменьшить количество ошибок.
Уменьшите количество магии в Joomla — в Joomla есть большое количество волшебных файлов, названия которых вам нужно угадать. Это увеличивает количество времени, которое люди, новички в Joomla, должны потратить на изучение этих концепций. Представление конкретного класса в расширениях позволяет нам легко проверять совместимость расширений с другими расширениями (например, категориями и ассоциациями).

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

Глобальная инъекция зависимостей очень слабо заменяет класс JFactory. Однако его не следует ошибочно принимать за прямую замену.

Примечание для обновлений

Как правило, вы не должны напрямую заменять вызовы JFactory в контейнере. В большинстве случаев вам следует либо вывести объект из приложения, либо использовать внедрение зависимостей в свой класс.

Поэтому, например, в ваших контроллерах в CMS вместо замены \Joomla\CMS\Factory::getDocument() рассмотрите возможность использования $this->app->getDocument(). Это использует введенное приложение и, следовательно, облегчает тестирование.

Создание объекта в контейнере

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

// Предполагается, что у нас есть экземпляр контейнера Joomla
$container->share(
	LoggerInterface::class,
	function (Container $container)
	{
		return \Joomla\CMS\Log\Log::createDelegatedLogger();
	},
	true
);

Функция share принимает два обязательных параметра и необязательный третий параметр.

Имя службы (service) почти всегда является именем класса, который вы создаете
Анонимная функция принимает один параметр — экземпляр контейнера (это позволяет извлекать любые зависимости из контейнера). Возвращаемые данные — это услуга, которую вы хотите поместить в контейнер
(необязательно). Это логическое значение определяет, защищена ли служба (т.е. разрешено ли кому-либо другому переопределять ее в контейнере). Как правило, для основных сервисов Joomla, таких как объекты сеанса, это верно.

Давайте теперь рассмотрим более сложный пример:

$container->alias('AmazingApiRouter', Joomla\CMS\Router\ApiRouter::class)
	->share(
	\Joomla\CMS\Router\ApiRouter::class,
	function (Container $container)
	{
		return new \Joomla\CMS\Router\ApiRouter($container->get(\Joomla\CMS\Application\ApiApplication::class));
	},
	true
);

Здесь вы можете видеть, что мы сделали две дополнительные вещи — мы начали использовать зависимости (маршрутизатор api извлекает приложение api из контейнера), а также создали псевдоним для маршрутизатора. Это означает, что, хотя контейнер распознает, что если ему нужно создать экземпляр ApiRouter, он может это сделать. Но в нашем коде, чтобы все было просто, мы также можем запустить Factory::getContainer()->get('AmazingApiRouter') для извлечения нашего маршрутизатора.

В то время как в Joomla наши провайдеры могут выглядеть более сложными, чем эти, потому что логика создания объектов внутри анонимной функции более сложная, — все они следуют этой базовой идее.

Поставщики (Providers)

Поставщики в Joomla — это способ регистрации зависимости в контейнере службы. Для этого создайте класс, реализующий интерфейс Joomla\DI\ServiceProviderInterface. Это дает вам метод регистрации, содержащий контейнер. Затем вы можете снова использовать метод общего доступа, чтобы добавить любое количество объектов в контейнер. Затем вы можете зарегистрировать полученное в контейнере с помощью метода "\Joomla\DI\Container::registerServiceProvider" в контейнере. Вы можете увидеть, где мы регистрируем всех основных поставщиков услуг здесь, в методе \Joomla\CMS\Factory::createContainer

Контейнеры компонентов (Component Containers)

Каждый компонент также имеет свой собственный контейнер (который находится в разделе администратора Joomla). Однако этот контейнер не подвергается воздействию. Это просто для того, чтобы получить системные зависимости и позволить классу представлять ваше расширение. Этот класс является классом расширений и, как минимум, должен реализовывать соответствующий интерфейс типа расширений. Например, компонент должен реализовать интерфейс \Joomla\CMS\Extension\ComponentInterface (можно найти на GitHub).

Для получения полной информации о реализации этого в вашем расширении мы рекомендуем прочитать статью Разработка компонента MVC.

Использование контейнера компонентов в другом расширении

Вы можете легко захватить контейнер другого расширения с помощью объекта CMSApplication. Например:

Factory::getApplication()->bootComponent('com_content')->getMVCFactory()->createModel('Articles', 'Site');

Получите контейнер com_content, получите MVC Factory и получите модель Articles из интерфейса Joomla. И это будет работать в любом расширении в интерфейсе, бэкэнде или API Joomla (в отличие от старого метода LegacyModel::getInstance())

Подробнее

В документах Joomla Framework есть отличный пример того, почему внедрение зависимостей полезно для вашего приложения и как DIC помогает его структурировать. Прочтите это здесь.

Перевод с английского официальной документации Joomla 4:
https://docs.joomla.org/J4.x:Dependency_Injection_in_Joomla_4

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)