- Введение
- Когда использовать фасады
- Как работают фасады
- Фасады в реальном времени
- Справочник по классу Facade
#Введение
Во всей документации Laravel вы увидите примеры кода, которые взаимодействуют с функциями Laravel через «фасады». Фасады предоставляют «статический» интерфейс к классам, доступным в сервис-контейнере приложения. Laravel поставляется с множеством фасадов, которые обеспечивают доступ почти ко всем функциям Laravel.
Фасады Laravel служат «статическими прокси» для базовых классов в сервис-контейнере, обеспечивая лаконичный и выразительный синтаксис при сохранении большей тестируемости и гибкости по сравнению с традиционными статическими методами. Не обязательно полностью понимать, как работают фасады — просто следуйте за процессом и продолжайте изучать Laravel.
Все фасады Laravel определены в пространстве имён Illuminate\Support\Facades. Поэтому мы можем легко получить доступ к фасаду следующим образом:
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Route;
Route::get('/cache', function () {
return Cache::get('key');
});
Во многих примерах документации Laravel используются фасады для демонстрации различных возможностей фреймворка.
#Вспомогательные функции
В дополнение к фасадам, Laravel предлагает множество глобальных «вспомогательных функций», которые упрощают взаимодействие с распространёнными функциями Laravel. Некоторые из часто используемых вспомогательных функций — view, response, url, config и другие. Каждая вспомогательная функция документируется вместе с соответствующей функцией; полный список доступен в отдельной документации по вспомогательным функциям.
Например, вместо использования фасада Illuminate\Support\Facades\Response для создания JSON-ответа, можно просто использовать функцию response. Поскольку вспомогательные функции доступны глобально, вам не нужно импортировать классы для их использования:
use Illuminate\Support\Facades\Response;
Route::get('/users', function () {
return Response::json([
// ...
]);
});
Route::get('/users', function () {
return response()->json([
// ...
]);
});
#Когда использовать фасады
Фасады имеют множество преимуществ. Они обеспечивают лаконичный и запоминающийся синтаксис, позволяющий использовать функции Laravel без необходимости помнить длинные имена классов, которые нужно внедрять или настраивать вручную. Кроме того, благодаря особенностям динамического вызова методов PHP, их легко тестировать.
Однако при использовании фасадов нужно соблюдать осторожность. Основная опасность фасадов — «разрастание» ответственности класса. Поскольку фасады очень просты в использовании и не требуют внедрения, легко допустить, чтобы класс рос и использовал множество фасадов одновременно. При использовании внедрения зависимостей этот риск снижается за счёт визуального сигнала — большого конструктора, который указывает на слишком большой класс. Поэтому при использовании фасадов внимательно следите за размером класса, чтобы область его ответственности оставалась узкой. Если класс становится слишком большим, рассмотрите возможность разделения его на несколько меньших классов.
#Фасады против внедрения зависимостей
Одно из главных преимуществ внедрения зависимостей — возможность подменять реализации внедряемого класса. Это полезно при тестировании, так как можно внедрить мок или стаб и проверить, что нужные методы были вызваны.
Обычно невозможно замокать или застабить действительно статический метод класса. Однако поскольку фасады используют динамические методы для проксирования вызовов к объектам, полученным из сервис-контейнера, мы можем тестировать фасады так же, как и внедрённые экземпляры классов. Например, для следующего маршрута:
use Illuminate\Support\Facades\Cache;
Route::get('/cache', function () {
return Cache::get('key');
});
С помощью встроенных методов тестирования фасадов Laravel можно написать следующий тест, чтобы проверить, что метод Cache::get был вызван с ожидаемым аргументом:
use Illuminate\Support\Facades\Cache;
/**
* Пример базового функционального теста.
*/
public function test_basic_example(): void
{
Cache::shouldReceive('get')
->with('key')
->andReturn('value');
$response = $this->get('/cache');
$response->assertSee('value');
}
#Фасады против вспомогательных функций
Помимо фасадов, Laravel включает множество «вспомогательных» функций, которые выполняют распространённые задачи, такие как генерация представлений, вызов событий, отправка заданий в очередь или отправка HTTP-ответов. Многие из этих вспомогательных функций делают то же самое, что и соответствующий фасад. Например, следующий вызов фасада и вспомогательной функции эквивалентны:
return Illuminate\Support\Facades\View::make('profile');
return view('profile');
Практической разницы между фасадами и вспомогательными функциями нет. При использовании вспомогательных функций вы можете тестировать их так же, как соответствующий фасад. Например, для следующего маршрута:
Route::get('/cache', function () {
return cache('key');
});
Вспомогательная функция cache вызывает метод get у класса, лежащего в основе фасада Cache. Поэтому, даже используя вспомогательную функцию, мы можем написать следующий тест, чтобы проверить, что метод был вызван с ожидаемым аргументом:
use Illuminate\Support\Facades\Cache;
/**
* Пример базового функционального теста.
*/
public function test_basic_example(): void
{
Cache::shouldReceive('get')
->with('key')
->andReturn('value');
$response = $this->get('/cache');
$response->assertSee('value');
}
#Как работают фасады
В приложении Laravel фасад — это класс, который предоставляет доступ к объекту из контейнера. Механизм, который это обеспечивает, реализован в классе Facade. Фасады Laravel и любые ваши собственные фасады будут наследовать базовый класс Illuminate\Support\Facades\Facade.
Базовый класс Facade использует магический метод __callStatic(), чтобы перенаправлять вызовы с фасада к объекту, полученному из контейнера. В примере ниже вызывается система кэширования Laravel. На первый взгляд может показаться, что статический метод get вызывается у класса Cache:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use Illuminate\Support\Facades\Cache;
use Illuminate\View\View;
class UserController extends Controller
{
/**
* Показать профиль указанного пользователя.
*/
public function showProfile(string $id): View
{
$user = Cache::get('user:'.$id);
return view('profile', ['user' => $user]);
}
}
Обратите внимание, что в начале файла мы «импортируем» фасад Cache. Этот фасад служит прокси для доступа к реализации интерфейса Illuminate\Contracts\Cache\Factory. Все вызовы через фасад будут переданы базовому экземпляру сервиса кэширования Laravel.
Если посмотреть на класс Illuminate\Support\Facades\Cache, вы увидите, что у него нет статического метода get:
class Cache extends Facade
{
/**
* Получить зарегистрированное имя компонента.
*/
protected static function getFacadeAccessor(): string
{
return 'cache';
}
}
Вместо этого фасад Cache наследует базовый класс Facade и определяет метод getFacadeAccessor(). Его задача — вернуть имя привязки в сервис-контейнере. Когда пользователь вызывает любой статический метод фасада Cache, Laravel разрешает привязку cache из сервис-контейнера и выполняет запрошенный метод (в данном случае get) у этого объекта.
#Фасады в реальном времени
С помощью фасадов в реальном времени вы можете обращаться с любым классом вашего приложения так, как будто это фасад. Чтобы показать, как это работает, сначала рассмотрим код без использования фасадов в реальном времени. Например, предположим, что у нашей модели Podcast есть метод publish. Однако для публикации подкаста нам нужно внедрить экземпляр Publisher:
<?php
namespace App\Models;
use App\Contracts\Publisher;
use Illuminate\Database\Eloquent\Model;
class Podcast extends Model
{
/**
* Опубликовать подкаст.
*/
public function publish(Publisher $publisher): void
{
$this->update(['publishing' => now()]);
$publisher->publish($this);
}
}
Внедрение реализации издателя в метод позволяет легко тестировать метод изолированно, так как мы можем замокать внедрённый издатель. Однако это требует всегда передавать экземпляр издателя при вызове метода publish. Используя фасады в реальном времени, мы сохраняем такую же тестируемость, но не нужно явно передавать экземпляр Publisher. Чтобы создать фасад в реальном времени, добавьте префикс Facades к пространству имён импортируемого класса:
<?php
namespace App\Models;
use App\Contracts\Publisher;
use Facades\App\Contracts\Publisher;
use Illuminate\Database\Eloquent\Model;
class Podcast extends Model
{
/**
* Опубликовать подкаст.
*/
public function publish(Publisher $publisher): void
public function publish(): void
{
$this->update(['publishing' => now()]);
$publisher->publish($this);
Publisher::publish($this);
}
}
При использовании фасада в реальном времени реализация издателя будет разрешена из сервис-контейнера по части имени интерфейса или класса, которая идёт после префикса Facades. При тестировании можно использовать встроенные средства тестирования фасадов Laravel для мокирования этого вызова:
<?php
namespace Tests\Feature;
use App\Models\Podcast;
use Facades\App\Contracts\Publisher;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
class PodcastTest extends TestCase
{
use RefreshDatabase;
/**
* A test example.
*/
public function test_podcast_can_be_published(): void
{
$podcast = Podcast::factory()->create();
Publisher::shouldReceive('publish')->once()->with($podcast);
$podcast->publish();
}
}
#Справочник по классу Facade
Ниже приведён список всех фасадов и их базовых классов. Это удобный инструмент для быстрого перехода к документации API для конкретного фасада. Также указан ключ привязки в сервис-контейнере, если применимо.