При использовании любого инструмента в «реальном мире» вы чувствуете себя более уверенно, если понимаете, как работает этот инструмент. Разработка приложений ничем не отличается. Когда вы понимаете, как работают ваши инструменты разработки, вы чувствуете себя более комфортно и уверенно, используя их.
Цель этого документа – дать вам хороший общий обзор того, как работает фреймворк Laravel. Если вы лучше узнаете общую структуру, то все станет менее «волшебным», и вы будете более уверены при создании своих приложений. Если вы не сразу поняли все термины, то не унывайте! Просто попытайтесь получить общее представление о том, что происходит, и ваши знания будут расти по мере изучения других разделов документации.
Точкой входа для всех запросов к приложению Laravel является файл public/index.php. Все запросы направляются в этот файл конфигурацией вашего веб-сервера (Apache / Nginx). Файл index.php не содержит большого количества кода. Скорее, это отправная точка для загрузки остальной части фреймворка.
Файл index.php загружает автозагрузчик, созданный менеджером пакетов Composer, а затем извлекает экземпляр приложения Laravel из bootstrap/app.php. Первым действием, предпринимаемым самим Laravel, является создание экземпляра приложения / контейнера служб.
Затем входящий запрос отправляется либо HTTP-ядру, либо ядру консоли, в зависимости от типа запроса, поступающего в приложение. Эти два ядра служат центральным местом, через которое проходят все запросы. А пока давайте сосредоточимся на ядре HTTP, которое находится в app/Http/Kernel.php.
HTTP-ядро расширяет класс Illuminate\Foundation\Http\Kernel, который определяет массив загрузчиков (bootstrappers), которые будут запускаться до выполнения запроса. Эти загрузчики настраивают обработку ошибок, настраивают ведение журнала, определяют среду приложения и выполняют другие задачи, которые необходимо выполнить до фактической обработки запроса. Обычно эти классы обрабатывают внутреннюю конфигурацию Laravel, о которой вам не нужно беспокоиться.
Ядро HTTP также определяет список HTTP-посредников, через которые должны пройти все запросы, прежде чем они будут обработаны приложением. Эти посредники обрабатывают чтение и запись HTTP-сессий, определяют, находится ли приложение в режиме обслуживания, проверяют токен CSRF и многое другое. Мы поговорим об этом позже.
Сигнатура метода handle HTTP-ядра довольно проста: он получает запрос (Request) и возвращает ответ (Response). Думайте о ядре как о большом черном ящике, который представляет все ваше приложение. Подайте ему HTTP-запросы, и он вернет HTTP-ответы.
Одним из наиболее важных действий начальной загрузки ядра является загрузка поставщиков служб вашего приложения. Поставщики служб несут ответственность за загрузку всех различных компонентов фреймворка, таких как компоненты БД, очереди, валидации и маршрутизации. Все поставщики служб приложения настраиваются в массиве providers конфигурационного файла config/app.php.
Laravel будет перебирать этот список поставщиков и создавать экземпляры каждого из них. После создания экземпляров поставщиков, будет вызван метод register всех поставщиков. Затем, как только все поставщики будут зарегистрированы, будет вызван метод boot каждого из них. Это сделано для того, чтобы поставщики служб имели возможность зависимости от каждого из зарегистрированных и доступных «связываний контейнера» к моменту выполнения их метода boot.
По сути, каждая основная функция Laravel загружается и настраивается поставщиком служб. Поскольку они запускают и настраивают так много функций, предлагаемых фреймворком, поставщики служб являются наиболее важным аспектом всего процесса начальной загрузки Laravel.
Одним из наиболее важных поставщиков служб в вашем приложении является App\Providers\RouteServiceProvider. Этот поставщик загружает файлы маршрутов, содержащиеся в каталоге routes приложения. Откройте код RouteServiceProvider и посмотрите, как он работает!
После того, как приложение было загружено и все поставщики служб зарегистрированы, Request будет передан маршрутизатору для исполнения. Маршрутизатор отправит запрос на маршрут или контроллер, а также запустит посредник для конкретного маршрута.
Посредники обеспечивают удобный механизм фильтрации или интерпретации HTTP-запросов, поступающих в ваше приложение. Например, Laravel содержит посредника, который проверяет аутентификацию пользователя вашего приложения. Если пользователь не аутентифицирован, посредник перенаправит пользователя, например, на экран входа в систему. Однако, если пользователь аутентифицирован, посредник позволит запросу продолжить работу в приложении. Некоторые посредники назначаются всем маршрутам в приложении, например, определенным в свойстве $middleware вашего ядра HTTP, тогда как некоторые назначаются только для определенных маршрутов или групп маршрутов. Вы можете узнать больше о посредниках, прочитав полную документацию по посредникам.
Если запрос проходит через всех посредников, назначенных определенному маршруту, то метод маршрута или контроллера будет выполнен, а ответ, возвращенный методом маршрута или контроллера, будет отправлен обратно через цепочку посредников маршрута.
Когда метод маршрута или контроллера вернет ответ, тогда ответ отправится обратно через посредников маршрута, обеспечивая приложению возможность изменения или проверки исходящего ответа.
Наконец, как только ответ проходит через посредников, метод handle ядра HTTP возвращает объект ответа, а файл index.php вызывает метод send для возвращенного ответа. Метод send отправляет содержимое ответа в веб-браузер пользователя. Мы завершили наш путь через весь жизненный цикл запроса Laravel!
Поставщики служб действительно являются ключом к начальной загрузке приложения Laravel. Экземпляр приложения создается, поставщики служб регистрируются, и запрос передается загружаемому приложению. Это действительно так просто!
Очень важно иметь четкое представление о том, как создается и загружается приложение Laravel через поставщиков служб. Поставщики служб вашего приложения хранятся в каталоге app/Providers.
По умолчанию поставщик AppServiceProvider относительно пуст. Этот поставщик является отличным местом для добавления собственной инициализации и связываний контейнера служб вашего приложения. Для больших приложений вы можете создать несколько поставщиков, каждый из которых детализирует начальную загрузку для конкретных сервисов, используемых вашим приложением.