Жизненный цикл запроса

Вступление

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

Цель этого документа — дать вам детальный обзор того, как работает система Laravel. Хорошее знакомство с фреймворком позволит вам почувствовать меньше "магии", и вы будете более уверенно создавать свои приложения. Если вы не понимаете всех терминов сразу, не унывайте! Просто постарайтесь получить базовое представление о происходящем, и ваши знания будут расти по мере того, как вы будете изучать другие разделы документации.

Обзор жизненного цикла

Первые шаги

Точкой входа для всех запросов к приложению Laravel является файл public/index.php. Все запросы направляются к этому файлу конфигурацией вашего веб-сервера (Apache / Nginx). Файл index.php не содержит большого количества кода. Скорее, он является отправной точкой для загрузки остальной части фреймворка.

Файл index.php подключает сгенерированный Composer`ом автозагрузчик, а затем получает экземпляр приложения Laravel из скрипта bootstrap/app.php. Первое действие, предпринятое самим Laravel — это создание экземпляра приложения / service container.

HTTP / Console ядра

Далее входящий запрос посылается либо на ядро HTTP, либо на консольное ядро, в зависимости от типа поступающего запроса. Эти два ядра служат центральным местом, через которое проходят все запросы. А пока давайте сосредоточимся на ядре HTTP, которое находится в app/Http/Kernel.php.

Ядро HTTP расширяет класс Illuminate\Foundation\Http\Kernel, определяющий массив bootstrappers, которые будут запущены до выполнения запроса. Эти загрузчики настраивают обработку ошибок, ведение логов, обнаружение среды приложения и другие задачи, которые необходимо выполнить до того, как запрос будет обработан.

Ядро HTTP также определяет список посредников (middleware) HTTP, через которые должны пройти все запросы, прежде чем они будут обработаны приложением. Эти посредники обрабатывают чтение и запись HTTP-сессии, определяют, находится ли приложение в режиме обслуживания, проверяют CSRF-токен и многое другое.

Сигнатура метода handle ядра HTTP достаточно проста: получить Request и вернуть Response. Считайте, что ядро — это большой черный ящик, представляющий всё ваше приложение. Направьте ему HTTP-запросы и он вернет HTTP-ответы.

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

Одно из самых важных действий Ядра при загрузке — это загрузка service providers для приложения. Все поставщики услуг настраиваются в массиве провайдеров конфигурационного файла config/app.php. Сначала метод register вызовет всех провайдеров, затем, после регистрации всех провайдеров, будет вызван метод boot.

Сервис-провайдеры отвечают за загрузку различных компонентов фреймворка, таких как база данных (database), очередь (queue), валидация (validation) и компоненты маршрутизации (routing). Так как они осуществляют загрузку и конфигурирование каждой функции, предлагаемой фреймворком, поставщики услуг являются наиболее важным аспектом всего процесса загрузки Laravel.

Отправка запроса

Как только приложение будет загружено и все сервис-провайдеры будут зарегистрированы, Request будет передан маршрутизатору. Маршрутизатор отправит запрос на маршрут или контроллер, а также запустит посредника для маршрута.

Focus On Service Providers

Сервис-провайдеры являются ключевыми в загрузке приложения Laravel. Экземпляр приложения создается, сервис-провайдеры регистрируются, и запрос передается в загрузчик приложения. Это действительно так просто!

Иметь твердое представление о том, как построено приложение Laravel и как оно загружается через сервис-провайдеров, очень ценно. По умолчанию поставщики приложения хранятся в каталоге app/Providers.

По умолчанию AppServiceProvider почти пуст. Этот провайдер — отличное место для добавления собственных привязок к загрузочным и сервисным контейнерам приложения. Для больших приложений можно создать несколько провайдеров, каждый из которых будет иметь более гранулярный тип загрузочной обвязки.