Что такое фасад laravel

Laravel Framework Russian Community

Пролог

Начало работы

Основы архитектуры

Основы

Фронтенд

Безопасность

Копаем глубже

База данных

Eloquent ORM

Тестирование

Официальные пакеты

Фасады

Введение

Фасады предоставляют «статический» интерфейс к классам, доступным в сервис-контейнере. Laravel поставляется со множеством фасадов, которые предоставляют доступ практически ко всем функциям Laravel. Фасады Laravel служат «статическими прокси» для основополагающих классов в сервис-контейнере, предоставляя преимущество лаконичного, выразительного синтаксиса, сохраняя при этом большую тестируемость и гибкость по сравнению с обычными статическими методами.

В документации Laravel фасады будут использоваться во многих примерах, чтобы продемонстрировать различный функционал фреймворка.

Когда использовать фасады

У фасадов множество преимуществ. Они обеспечивают лаконичный, запоминающийся синтаксис, который позволяет использовать функции Laravel без необходимости запоминать длинные названия классов, которые нужно вставить или настроить вручную. Кроме того, из-за их уникального использования динамических методов PHP, их легко тестировать.

При создании стороннего пакета, который взаимодействует с Laravel, лучше внедрять контракты Laravel вместо использования фасадов. Так как пакеты создаются вне самого Laravel, у вас не будет доступа к хелперам тестирования Laravel.

Фасады в сравнении с Внедрением зависимостей

Одним из основных преимуществ внедрения зависимостей является возможность замены реализаций внедряемого класса. Это полезно во время тестирования, так как вы можете внедрить заглушку и утверждать, что на заглушке есть различные методы.

Для настоящих статических методов обычно невозможно сделать заглушку. Однако, поскольку фасады используют динамические методы для вызова метода прокси для объектов, отделенных от сервис-контейнеров, мы фактически можем тестировать фасады так же, как мы бы тестировали экземпляр внедренного класса. Например, учитывая следующий роут:

Мы можем написать следующий тест, чтобы проверить, что метод Cache::get был вызван с ожидаемым аргументом:

Фасады в сравнении с Хелперами

Помимо фасадов, Laravel включает множество вспомогательных функций, хелперов, которые могут выполнять общие задачи, такие как формирование шаблонов, запуск событий, постановка задач в очередь или отправка HTTP-ответов. Многие из этих хелперов выполняют ту же функцию, как и соответствующий фасад. Например, этот вызов фасада и этот вызов хелпера эквивалентны:

Нет никакой практической разницы между фасадами и хелперами. При использовании хелперов вы можете тестировать их точно так же, как и соответствующие фасады. Например, учитывая следующий роут:

Как работают фасады

Класс Facade использует магический метод PHP __callStatic() для перенаправления вызовов методов с вашего фасада на полученный объект из контейнера. В примере ниже делается обращение к механизму кэширования Laravel. На первый взгляд может показаться, что статический метод get принадлежит классу Cache :

Справочное описание классов фасадов

Ниже вы найдете каждый фасад и его основной класс. Это полезный инструмент для быстрой обработки документации API для данной корневой директории фасада. Ключ привязки сервис-контейнера также включен там, где это применимо.

Источник

Laravel 8 · Фасады

Введение

В документации Laravel вы увидите примеры кода, демонстрирующего взаимодействия с функционалом Laravel через «фасады». Фасады предоставляют «статический» интерфейс для классов, доступных в контейнере служб приложения. Laravel из коробки включает множество фасадов, обеспечивающих доступ почти ко всему функционалу Laravel.

Фасады Laravel служат «статическими прокси» для базовых классов в контейнере служб, обеспечивая преимущества краткого, выразительного синтаксиса при сохранении большей тестируемости и гибкости, чем традиционные статические методы. Если вы не совсем понимаете, как фасады работают под капотом – просто продолжайте изучать Laravel.

В документации Laravel во многих примерах будут использоваться фасады для демонстрации различного функционала фреймворка.

Глобальные помощники

Когда использовать фасады

У фасадов много преимуществ. Они предоставляют краткий, запоминающийся синтаксис, который позволяет вам использовать функции Laravel, не запоминая длинные имена классов, которые необходимо вводить или конфигурировать вручную. Более того, благодаря уникальному использованию динамических методов PHP их легко протестировать.

Однако при использовании фасадов необходимо соблюдать некоторую осторожность. Основная опасность фасадов – «разрастание» класса. Поскольку фасады настолько просты в использовании и не требуют внедрений, что легко сказывается на разрастании класса и использовании множества фасадов в одном классе. При использовании внедрения зависимостей этот потенциал снижается за счет визуальной обратной связи, которую дает большой конструктор, сигнализируя о том, что ваш класс становится слишком большим. Поэтому, используя фасады, обратите особое внимание на размер вашего класса, чтобы уровень его ответственности оставался узким. Если ваш класс становится слишком большим, рассмотрите возможность разделения его на несколько более мелких классов.

Фасады против внедрения зависимостей

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

Как правило, невозможно имитировать или заглушить действительно статический метод класса. Однако, поскольку фасады используют динамические методы для проксирования вызовов методов к объектам, извлекаемым из контейнера служб, мы фактически можем тестировать фасады так же, как тестировали бы внедренный экземпляр класса. Например, учитывая следующий маршрут:

Используя методы тестирования фасадов Laravel, мы можем написать следующий тест, чтобы проверить, что метод Cache::get был вызван с ожидаемым аргументом:

Фасады против глобальных помощников

Помимо фасадов, Laravel включает в себя множество «вспомогательных» функций, которые могут выполнять общие задачи, такие как генерация шаблонов, запуск событий, запуск заданий или отправка HTTP-ответов. Многие из этих вспомогательных функций выполняют ту же функцию, что и соответствующий фасад. Например, этот вызов фасада и вызов помощника эквивалентны:

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

Как фасады работают

Фасады в реальном времени

Справочник фасадов

Ниже вы найдете каждый фасад и его базовый класс. Это полезный инструмент для быстрого поиска в документации API. Ключ привязки в контейнере служб также указан, где это возможно.

Источник

Фасады

Введение

Фасады предоставляют «статический» интерфейс к классам, доступным в сервис-контейнере. Laravel поставляется со множеством фасадов, предоставляющих доступ почти ко всем возможностям Laravel. Фасады Laravel служат «статическими прокси» для классов в сервис-контейнере, обеспечивая преимущества краткого выразительного синтаксиса, и поддерживая большую тестируемость и гибкость, чем традиционные статические методы.

Во многих примерах в документации по Laravel используются фасады для демонстрации различных возможностей фреймворка.

Когда стоит использовать фасады

Фасады имеют много преимуществ. Они обеспечивают лаконичный, запоминающийся синтаксис, который позволяет вам использовать возможности Laravel, не запоминая длинные имена классов, которые должны внедряться или настраиваться вручную. Более того, благодаря уникальному использованию динамических методов PHP они легко тестируются.

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

При создании стороннего пакета, взаимодействующего с Laravel, лучше внедрять контракты Laravel вместо использования фасадов. Поскольку пакеты создаются вне самого Laravel, у вас не будет доступа к вспомогательным функциям тестирования фасадов.

Фасады или внедрение зависимостей

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

Обычно невозможно сделать макет или заглушку метода настоящего статического класса. Но поскольку фасады используют динамические методы для передачи вызовов к объектам, извлекаемым из сервис-контейнера, мы можем тестировать фасад точно так же, как тестировали бы внедрённый экземпляр класса. Например, возьмём следующий маршрут:

Мы можем написать следующий тест, чтобы проверить, что метод PHP Cache :: get () был вызван с ожидаемым нами аргументом:

Фасады или вспомогательные функции

Кроме фасадов в Laravel есть множество «вспомогательных» функций, которые могут выполнять общие задачи, такие как генерация представлений, запуск событий, постановка задач и отправка HTTP-откликов. Многие из этих вспомогательных функций выполняют те же задачи, что и соответствующий фасад. Например, эти вызовы фасада и вспомогательной функции эквивалентны:

Нет абсолютно никакой фактической разницы между фасадами и вспомогательными функциями. При использовании вспомогательных функций вы можете тестировать их точно так же, как тестировали бы соответствующий фасад. Например, возьмём следующий маршрут:

Как работают фасады

Базовый класс PHP Facade использует магический метод PHP PHP __callStatic () для перенаправления вызовов методов с вашего фасада на полученный объект. В примере ниже делается обращение к механизму кэширования Laravel. На первый взгляд может показаться, что метод PHP get () принадлежит классу PHP Cache :

Таким образом, вызов PHP Cache :: get () может быть переписан так:

Импорт фасадов

Помните, если вы используете фасад в контроллере, который находится в пространстве имён, то вам надо импортировать класс фасада в пространство имён. Все фасады живут в глобальном пространстве имён:

Создание фасадов

Создать фасад в вашем приложении или пакете довольно просто. Вам нужны только три вещи:

Посмотрим на следующий пример. Здесь определён класс PHP PaymentGateway \ Payment :

Нам нужно, чтобы этот класс извлекался из сервис-контейнера, поэтому давайте добавим для него привязку (binding):

Дальше мы можем создать класс нашего фасада:

Об автозагрузке псевдонимов

Фасады-заглушки

Юнит-тесты играют важную роль в том, как именно работают фасады. На самом деле возможность тестирования — основная причина, по которой фасады вообще существуют. Эта тема подробнее раскрыта в разделе документации о фасадах-заглушках.

Соответствие фасадов и классов

В таблице ниже перечислены все фасады и соответствующие им классы. Это полезный инструмент для быстрого начала работы с документацией по API данного корня фасадов. Также указаны ключи привязок в сервис-контейнере, где это нужно.

Комментарии (2)

Источник

Что Представляют Собой Фасады в Laravel 5?

Russian (Pусский) translation by Sergey Zhuk (you can also view the original English article)

Лучше всего шаблоны проектирования были описаны Мартином Фаулером:

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

Что представляет собой шаблон Фасад?

Фасад очень похож на шаблоны адаптер и декоратор. Адаптер работает как мост между двумя несовместимыми интерфейсами, в то время как декоратор является более сложными и используется для динамического изменения поведения объектов.

Чем Являются Фасады Laravel?

Приятный синтаксис, который используется в Laravel, делает написание кода чистым и легким в понимании. Фасады Laravel фактически являются синтаксическим сахаром для сервисов.

Давайте на примере рассмотрим фасад Laravel и то, как он работает. Фасад Cache в Laravel выглядит следующим образом:

Хотя может показаться, что здесь используются статические методы, в действительности же Laravel предоставляет интерфейс для классов, которые доступны через контейнер зависимостей приложения. Как вы уже возможно знаете, код, представленный выше, эквивалентен следующему:

Псевдонимы устанавливаются автоматически автозагрузчиком Laravel. Устанавливая классу псевдоним Cache, мы создаем связь с фасадом. Это несомненно поможет людям, которые используют фасады, чувствовать себя комфортнее с вашим кодом.

Следующие три метода имеют огромное значение при создании фасада:

Реализация методов фасада:

Как показано в последней строчке статьи, в методе resolveFacadeInstance Laravel возвращает объект сервиса. Так как сервис является просто объектом оригинального класса, можно слетать вывод, что фасад Laravel не попадает под определение фасадов Банды Четырех. Он просто является сервисом. В отличие от фасадов Laravel, настоящие фасады делают написание юнит тестов достаточно трудоемким занятием, а иногда даже невозможным, из-за создания жестко прописанных зависимостей.

Для тех же кто считает, что инъекция зависимостей через конструктор, является лучшим выбором, чем использование фасадов Laravel, я бы хотел сообщить вам, что можно использовать некоторые дополнительные настройки.

Как Создавать Фасады Laravel

Мне нужно создать фасад для проверки файлов, который будет отвечать за проверку того, является ли входной файл формата pdf или нет. Для того чтобы сделать это, сначала необходимо создать класс IsPdf в App/MyFacade/IsPdf.php :

Затем нужно связать класс с поставщиком сервиса. Нужно будет создать нового поставщика сервиса в файле App\Providers\IsPdfServiceProvider :

Последним шагом будет регистрация фасада в config/app.php :

Поздравляю! Вы успешно создали фасад Laravel. Не стесняйтесь проверить ваш фасад с помощью кода, например:

Заключение

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

Для получения дополнительных ресурсов о Laravel, не забудьте проверить предложения.

Кто знает, может эта статья наоборот сподвигнет вас на разработку кода, независимого от фреймворков, и вообще заставит позабыть о фасадах! Удачи!

Источник

Laravel Framework Russian Community

Prologue

Getting Started

Architecture Concepts

The Basics

Frontend

Security

Digging Deeper

Database

Eloquent ORM

Testing

Official Packages

Фасады

Введение

Фасады предоставляют «статический» интерфейс к классам, доступным в сервис-контейнере. Laravel поставляется со множеством фасадов, которые предоставляют доступ практически ко всем функциям Laravel. Фасады Laravel служат «статическими прокси» для основополагающих классов в сервис-контейнере, предоставляя преимущество лаконичного, выразительного синтаксиса, сохраняя при этом большую тестируемость и гибкость по сравнению с обычными статическими методами.

В документации Laravel фасады будут использоваться во многих примерах, чтобы продемонстрировать различный функционал фреймворка.

Когда использовать фасады

У фасадов множество преимуществ. Они обеспечивают лаконичный, запоминающийся синтаксис, который позволяет использовать функции Laravel без необходимости запоминать длинные названия классов, которые нужно вставить или настроить вручную. Кроме того, из-за их уникального использования динамических методов PHP, их легко тестировать.

При создании стороннего пакета, который взаимодействует с Laravel, лучше внедрять контракты Laravel вместо использования фасадов. Так как пакеты создаются вне самого Laravel, у вас не будет доступа к хелперам тестирования Laravel.

Фасады в сравнении с Внедрением зависимостей

Одним из основных преимуществ внедрения зависимостей является возможность замены реализаций внедряемого класса. Это полезно во время тестирования, так как вы можете внедрить заглушку и утверждать, что на заглушке есть различные методы.

Для настоящих статических методов обычно невозможно сделать заглушку. Однако, поскольку фасады используют динамические методы для вызова метода прокси для объектов, отделенных от сервис-контейнеров, мы фактически можем тестировать фасады так же, как мы бы тестировали экземпляр внедренного класса. Например, учитывая следующий роут:

Мы можем написать следующий тест, чтобы проверить, что метод Cache::get был вызван с ожидаемым аргументом:

Фасады в сравнении с Хелперами

Помимо фасадов, Laravel включает множество вспомогательных функций, хелперов, которые могут выполнять общие задачи, такие как формирование шаблонов, запуск событий, постановка задач в очередь или отправка HTTP-ответов. Многие из этих хелперов выполняют ту же функцию, как и соответствующий фасад. Например, этот вызов фасада и этот вызов хелпера эквивалентны:

Нет никакой практической разницы между фасадами и хелперами. При использовании хелперов вы можете тестировать их точно так же, как и соответствующие фасады. Например, учитывая следующий роут:

Как работают фасады

Класс Facade использует магический метод PHP __callStatic() для перенаправления вызовов методов с вашего фасада на полученный объект из контейнера. В примере ниже делается обращение к механизму кэширования Laravel. На первый взгляд может показаться, что статический метод get принадлежит классу Cache :

Справочное описание классов фасадов

Ниже вы найдете каждый фасад и его основной класс. Это полезный инструмент для быстрой обработки документации API для данной корневой директории фасада. Ключ привязки сервис-контейнера также включен там, где это применимо.

Источник