Appserviceprovider laravel для чего
Laravel 8 · Поставщики служб
Введение
Поставщики служб – это центральное место начальной загрузки всех приложений Laravel. Ваше собственное приложение, а также все основные службы Laravel загружаются через поставщиков.
Но, что мы подразумеваем под «начальной загрузкой»? В общем, мы имеем в виду регистрацию элементов, включая регистрацию связываний контейнера служб, слушателей событий, посредников и даже маршрутов. Поставщики служб являются центральным местом для конфигурирования приложения.
В этой документации вы узнаете, как писать собственных поставщиков служб и регистрировать их в приложении Laravel.
Если вы хотите узнать больше о том, как Laravel обрабатывает запросы и работает изнутри, ознакомьтесь с нашей документацией по жизненному циклу запроса Laravel.
Написание поставщиков служб
Чтобы сгенерировать нового поставщика, используйте команду make:provider Artisan:
Метод register
Этот поставщик службы определяет только метод register и использует этот метод для определения реализации App\Services\Riak\Connection в контейнере служб. Если вы еще не знакомы с контейнером служб Laravel, ознакомьтесь с его документацией.
Свойства bindings и singletons
Если ваш поставщик службы регистрирует много простых связываний, вы можете использовать свойства bindings и singletons вместо ручной регистрации каждого связывания контейнера. Когда поставщик службы загружается фреймворком, он автоматически проверяет эти свойства и регистрирует их связывания:
Метод boot
Внедрение зависимости в методе boot
Вы можете указывать тип зависимостей в методе boot поставщика службы. Контейнер служб автоматически внедрит любые необходимые зависимости:
Регистрация поставщиков
Чтобы зарегистрировать поставщика, добавьте его в массив:
Отложенные поставщики
Если ваш поставщик регистрирует только связывания в контейнере служб, вы можете отложить его регистрацию до тех пор, пока одно из зарегистрированных связываний не понадобится. Отсрочка загрузки такого поставщика повысит производительность вашего приложения, так как он не загружается из файловой системы при каждом запросе.
Laravel составляет и сохраняет список всех служб, предоставляемых отложенными поставщиками служб, а также имя класса поставщика службы. Laravel загрузит поставщика службы только при необходимости в одной из этих служб.
Laravel: сервис-контейнеры и сервис-провайдеры. Что это и зачем?
Недавно перешел с фреймворка CodeIgniter (в котором была простая схема MVC) на изучение Laravel. Фреймворк очень понравился, но есть некоторые моменты, которые я никак не могу понять, сколько бы не читал документацию. В частности что такое сервис-контейнеры и сервис-провайдеры и зачем они нужны. Прошу помочь разобраться.
2 ответа 2
Ну что-ж, попробую объяснить. С Богом!
Все возможности я не опишу, просто попытаюсь дать представление и возможно (скорее всего) не совсем точно.
Введение:
Вообще эти штуки нужны, в первую очередь, для удобства, как плюс — они реализуют паттерн Dependency Injection. С него и начнём.
Красиво. Нет! Почему? А в друг нам понадобится, чтобы при создании класс myClassB принимал аргументы в свой конструктор? Придётся переписывать. Вы скажете: «перепишу, ничего страшного«, но если таких классов myClassA много, то тут уже косяк — надо разруливать, для этого и придумали паттерн, глянем на то, как надо:
Сложно описать, давайте покажем, переведем наш класс myClassA в контроллер:
Но нужно теперь и MyClassB создать. Сразу вспомним начало, нам нужно учитывать что класс должен что-то принимать. Создаем папочку app\MyClass и там файлик MyClassB.php с текстом:
Из документации видно, что внутри метода register() как раз и должны быть наши связывания, простенькие примеры:
Стоит также одним глазком глянуть в документацию на строчку:
Если вы откроете файл config/app.php, поставляемый с Laravel, то увидите массив providers. В нём перечислены все классы сервис-провайдеров, которые загружаются для вашего приложения.
Наш MyProvider тоже должен быть в этом списке.
Дочитали до конца? Бонусы:
Сервис-провайдеры в laravel для самых маленьких
Laravel отличный инструмент. Современный, быстроразвивающийся, функциональный, только не всегда понятный. И речь не про то, что доки на нерусском, а то, что они даже на родном для фреймворка английском не всегда показательны.
Лично я потратил 2 дня за курением доков на русском, английском, несколько туториалов переведенных с совсем нерусского на менее нерусский, это когда чуваки пишут русскими буквами, но в русские несмогли. Попадались несколько на немецком и парочка на испанском, там только смотреть на код можно, благо код — интернациональен! Проблема всех официальных и около оффициальных мануалов — они копируют друг друга. И задача в тысяче источников рассматривается однобоко. А ещё я посмотрел несколько видео обучалок, ненавижу видео-туторы, это полчаса времени про то, что можно в 5 абзацев вместить. Это я и попробую сделать.
Понятийный аппарат
Главная проблема — нифига не понятно кто это такие Сервис-провайдеры и как сними работать.
Тут надо уяснить простую вещь. Сервис провайдеры — это не функциональные блоки, т.е. какую-то логику класть в них как минимум странно. По сути это функции-посредники, необходимые, чаще всего, чтобы закидывать некоторые сервисы в некое «быстрое хранилище» Сервис-контейнер.
А вот и ещё одно прикольное понятие Сервис-контейнер. Попробую на пальцах — это «ящик», в котором хранятся все зарегистрированные сервисы, чтобы быстро к ним доступаться это раз, а самое главное:
Сервис-контейнер в Laravel — это мощное средство для управления зависимостями классов и внедрения зависимостей.
Так нам рассказывает официальная документация. Если не совсем понятно, то лучше бы тебе, милый дружок, почитать обзорные статьи на понятия контейнер внедрения зависимостей. Если очень грубо: иногда наш объект должен иметь доступ к чему-то из вне. Например, есть объект пользователь, который учится в школе. Можно все поля связанные со школой уместить внутрь пользователя. Но это, очевидно, будет избыточно, 2 разных пользователя могут учиться в одной школе, поэтому создаем отдельный объект школа. А чтобы пользователь мог получить инфу о школе, мы в конструктор передаем зависимость от некоего хранилища школы, интерфейс, который по запросу может вернуть объект школы. Т.е. теперь при создании пользователя он сможет дергать внешнее хранилище и получать требуемые данные. Таким образом объект замкнут сам в себе. Понимаешь?! Это как нарисовать сову! Ой, всё! Давай потом на эту тему поговорим.
Вернемся к нашему предмету.Сервис-контейнер хранит внутри себя некие сервисы. А что такое сервис? А вот это как раз тот самый функциональный блок, который нам нужен. Отправка смс, вывод статистики по чему-либо и т.д. Все зарегистрированные сервисы кэшируются в /var/www/bootstrap/cache/services.php, можно глянуть кто и что туда добавились
Нафига это надо? Можно ж по старинке всё делать, нужен класс, дернул, не нужен не дернул. Так-то оно так, но одно дело когда перфоратор у тебя на балконе лежит, ты пошел и взял, а другое дело, когда он в гараже, у отца, в другом городе, в Белоруссии, а ты в Гремании. Ну ты понял. Скорость и удобство.
Кодовое выражение
Допустим, мы поняли что такое сервис-провайдеры. А как с ними жить и как это выражается в печатных символах в любимой IDE’шке?
Есть короткий ответ, вот так:
Именно так написано в документации. И ты такой: «Аааа! Тут же вон оно… И чё?» А я был готов к этому вопросу, не зря ж уже 2ю неделю пишу этот опус.
Собственно, мы говорим: Мне нужно, чтобы в сервис контейнере лежал экземпляр класса Riak\Connection (за это отвечает строка — return new Connection(config(‘riak’))) с именем равным исходному имени класса (а за это отвечает Connection::class) и я хочу чтобы это был единственный инстанс ($this->app->singleton). И теперь, если в любом месте приложения я попытаюсь дернуть что-то с именем Connection, то мне вернется уже созданный объект из контейнера зависимостей.
Всё это прекрасно, но главная боль всё ещё в силе — ЗАЧЕМ?
Зачем?
Это хороший вопрос, если скорость доступа уже не будоражит, то вот тебе ещё один отличный пример.
Как бы я сейчас это реализовал. Для начала опишем контракт, которому должны следовать все создаваемые системы оповещения. По сути, если снизойти до понятий php, контракт это всего лишь интерфейс, да, вот так просто. Но контракт — звучит гордо.
Конечно, в большинстве своем, это просто договорённость, ты можешь не наследоваться, но интерфейс обяжет тебя создавать все методы которые могут быть вызваны извне. В нашем случае нам очень нужен метод send().
Добавим пару реализаций, как огоговаривалось выше — EmailAlarm, PhoneAlarm, ну и какой-нибудь экзотический ArmyAlarm, это если бы мы жили в америке, то к тебе приехал бы офицер национальной гвардии и дал команду на эвакуацию.
Так.. И как я это хочу подвязать к сервис-провайдеру? Немного увлекся. Ах вот! Теперь мы создаем наш сервис провайдер, который… А лучше я сначала напишу, а оптом объясню
Пояснения нужны? Ну лааадно уж. В зависимости от силы урагана будет создан тот или иной инстанс по оповещению, если всё слабенько, то по почте, если сильно — по телефону, при этом в коде мы будем везде вызывать ContractAlarm->send(). Ну круто же! Теперь нашему приложению совершенно пофигу что там и как реализуется, оно просто дергает некий абстрактный ContractAlarm, который имеем нужный метод send (кстати, имя можно было дать и более приличное, типа Alarmer, но это по желанию, говорят, что принято имя в контейнере и имя исходного класса лучше делать одинаковыми) Поэтому и удобно все реализации наследовать от контракта, чтобы всё было хорошо.
Надо ещё не забыть в config/app.php в секцию providers добавить наш новый сервис провайдер.
Выводы
Все эти штуки, дело сугубо добровольное. Никто тебя палками бить не будет если тебе впадлос юзать общепринятые решения. Хочешь, откажись от ООП вообще, сейчас это модно всякие извращения, можешь вообще всё внутри одной функции писать, чего ж нет? Типа очень жесткий Front Controller, который реально «Всё в одном месте» =) Но на счет «палками бить», ты подумай, а то вдруг всё же кто-то придет 
Update
Как мне справедливо накидали какашулей в комментариях, нужно признать, что я привёл не достаточно жизнеспособный пример.
Регистрация сервис-провайдеров происходит через файл конфига config/app.php, т.е. нет никакой явной передачи параметров. И вообще, как говорит документация и редит, в методе register должна быть исключительно привязка реализации к интерфейсу.
Первое что мне пришло в голову, это в другом сервисе, или даже в этом же сделать отдельную инициализацию объекта Hurricane. Но в этом случае фреймворк не гарантирует, что всё будет ок, потому что загрузка сервисов происходит в произвольном порядке. И не факт, что при инициализации ContractAlarm Ураган будет определён. Но (!) у сервис провайдера есть метод boot(), и вот этот метод однозначно гарантирует, что все другие сервисы уже инициированы. Поэтому весь код по определению Hurricane нужно из register() перенести в boot(). А Hurricane инициировать отдельным сервис-провайдером.
Правда, если включить голову, то становится понятно, что всё это избыточно и многословно. Сейчас я бы явно создал экземпляр внутри метода register(), т.е. прям DB::get. Либо же через файлы конфига достать нужные значения. Последнее это каноничное решение.
Итого: Передавать параметры в метод register() не надо. Нужны параметры, либо залезай в конфиги, либо в базу напрямую. Посылаю голову пеплом, спасибо за конструктив
Как зарегистрировать и использовать сервис провайдеры Laravel
Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)
Если вы когда-либо сталкивались с фреймворком Laravel, маловероятно, что вы не слышали о сервис контейнерах и поставщиках сервисов. Фактически, они являются основой фреймворка Laravel и делают весь тяжелый старт, когда вы запускаете экземпляр любого приложения Laravel.
В этой статье мы увидим, что такое контейнер служб, и после этого мы подробно обсудим сервис провайдеров В ходе этой статьи я также продемонстрирую, как создать свой пользовательский сервис провайдер в Laravel. Когда вы создаете сервис провайдера, вам также необходимо зарегистрировать его в своем приложении Laravel, чтобы можно было его использовать, поэтому мы это тоже рассмотрим.
Существует два важных метода: boot и register, которые может реализовать ваш сервис провайдер, и в последнем разделе этой статьи мы подробно их обсудим.
Прежде чем перейти к обсуждению поставщика услуг, я попытаюсь представить контейнер сервисов, поскольку он будет активно использоваться в вашей реализации сервис провайдера
Понимание сервисных контейнеров и сервис провайдеров
Что такое контейнер сервисов?
По словам официальной документации Laravel:
Таким образом, всякий раз, когда вам нужно встроить какой-либо компонент или службу, вы можете указать его в своем конструкторе или методе, и он будет автоматически встраиваться из контейнера служб, поскольку он содержит все, что вам нужно! Разве это не круто? Это избавляет вас от ручной компоновки компонентов и, таким образом, позволяет избежать жесткой связи в вашем коде.
Давайте посмотрим на быстрый пример, чтобы понять это.
Как вы можете видеть, SomeClass нуждается в экземпляре FooBar для создания экземпляра. Таким образом, в основном, у него есть зависимость, которую нужно встроить. Laravel делает это автоматически, просматривая контейнер и встраивая соответствующую зависимость.
Таким образом, сервис провайдер регистрирует все привязки контейнера, и это делается с помощью метода register реализации сервис провайдера.
Итак, это был контейнер в вашем распоряжении. В следующем разделе мы сосредоточимся на сервис провайдере, который является основной темой этой статьи!
Что такое сервис провайдер?
Давайте быстро взглянем на одного из основных сервис провайдеров, чтобы понять, что он делает. Откройте файл vender/laravel/framework/src/Illuminate/Cache/CacheServiceProvider.php.
И это была история о сервис провайдере. В следующем разделе мы обсудим, как создать специализированного сервис провайдера, чтобы вы могли зарегистрировать свои пользовательские сервисы в контейнере Laravel.
Создание собственного сервис провайдера
Как мы обсуждали ранее, существует два метода: register и booy, с которыми вы будете иметь дело большую часть времени, когда работаете с вашим пользовательским сервис провайдером.
Зарегистрируйте свой пользовательский сервис провайдер
Таким образом, вы создали своей собственный сервис провайдер. Замечательно! Затем вам нужно сообщить Laravel о своем специализированном сервис провайдере, чтобы он мог загрузить его вместе с другими провайдерами во время начальной загрузки.
Пройдемся по методам regsiter и boot
Здесь есть два важных момента:
И вот код где-то в вашем контроллере, где будет введена зависимость.
Это очень простой пример привязки класса. Фактически, в приведенном выше примере нет необходимости создавать сервис провайдер и внедрять метод register, как это было сделано, поскольку Laravel может автоматически разрешать его с помощью отражения.
Очень важное замечание из документации Laravel:
Нет необходимости связывать классы в контейнер, если они не зависят от каких-либо интерфейсов. Контейнеру не нужно указывать, как создавать эти объекты, поскольку он может автоматически разрешать эти объекты с помощью отражения.
С другой стороны, это было бы очень полезно, если бы вы связали интерфейс с определенной реализацией. Давайте рассмотрим пример, чтобы понять это.
Давайте создадим очень простой интерфейс в app/Library/Services/Contracts/CustomServiceInterface.php.
Теперь вместо привязки класса мы свяжем интерфейс. Снова откройте EnvatoCustomServiceProvider.php и измените код, как показано ниже.
Давайте быстро пересмотрим код контроллера.
Найдите следующую строку:
Аналогичным образом найдите это:
Это должно быть заменено на:
Тот же подход можно использовать, если вы хотите заменить любую основную реализацию своей собственной. И это не только метод bind, который вы могли бы использовать для привязки сервиса к контейнеру; Контейнер Laravel предоставляет различные способы привязки. Пожалуйста, ознакомьтесь с официальной документацией Laravel для полной справки.
Давайте рассмотрим несколько примеров, требующих реализации метода boot.
Вы хотите добавить свой собственный инструмент проверки поля формы в Laravel.
Если вы хотите зарегистрировать компоновщик отображений, то это идеальное место для этого! Фактически, можно сказать, что метод boot часто используется для добавления компоновщиков отображений!
Конечно, вам нужно в первую очередь импортировать фасад Illuminate\Support\Facades\View в своем сервис провайдере.
На этой же территории вы можете делиться данными и по нескольким представлениям!
Он также может использоваться для определения явных привязок к модели.
Это было несколько примеров, чтобы продемонстрировать использование метода boot. Чем больше вы погружаетесь в Laravel, тем больше причин вы найдете для его реализации!
И вот мы дошли до конца этой статьи. Надеюсь, вам понравились темы, которые в ней обсуждались.
Заключение
Именно обсуждение сервис провайдеров было главной достопримечательностью этой статьи, хотя мы начали нашу статью с контейнера для сервисов, поскольку это было важным компонентом для понимания работы сервис провайдера.
После этого мы разработали свой собственный сервис провайдер, а во второй половине статьи мы рассмотрели несколько практических примеров.
Для тех из вас, кто только начинает работать с Laravel или хочет расширить свои знания, сайт или приложение с расширениями, у нас есть множество вещей, которые вы можете изучать на Envato Market.
Если у вас есть какие-либо вопросы или комментарии, то обязательно оставляйте их в обратной связи ниже!
Laravel. Контракт, сервис-провайдер и фасад
Контракты или интерфейсы
Допустим, нам надо сохранять картинки в облако и на диск. И так вышло, что нужно использовать оба режима сохранения одновременно. Мы создаем контракт с перечнем методов и два класса, реализующих этот интерфейс.
Теперь можем где-нибудь воспользоваться нашими классами:
Поставщик услуг (Service Provider)
Допустим, нам не нужно параллельно использовать обе реализации сохранения картинок, а надо просто легко и быстро переключать режим с «сохранение на диск» на «сохранение в облако» и наоборот. Сервис провайдер как раз и предоставляет возможность легкого переключения между нескольким реализациями.
В методы singleton() и bind() первым параметром передается название контракта (интерфейса), а вторым параметром — анонимная функция, возвращающая один из классов, реализующих данный интерфейс. Лучше использовать метод singleton() т.к. он создает объект указанного класса только один раз, а при последующих обращениях возвращает тот же объект.
Внедрение зависимости (Dependency Injection)
Допустим, нам нужно использовать данный сервис-провайдер при сохранении данных, введенных пользователем в форме.
Мы передаем в метод store() две зависимости (Dependency Injection):
Можно внедрить зависимость не для отдельного метода, а для всего класса:
Если у провайдера есть зависимость
Допустим, что перед сохранением изображения мы хотим изменить его размер — нам нужен класс, который это умеет делать. Давайте его создадим, а потом передадим как зависимость классу, который сохраняет изображения.
И вносим изменения в сервис-провайдер ImageSaverServiceProvider :
Не нужно усложнять без необходимости
Очень важное замечание из документации Laravel:
Нет необходимости связывать классы в контейнер, если они не зависят от каких-либо интерфейсов. Контейнеру не нужно указывать, как создавать эти объекты, поскольку он может автоматически разрешать эти объекты с помощью отражения.
Мало того, если у класса SimpleImageSaver есть зависимость — например, класс SimpleImageResizer — Laravel разрешит и эту зависимость. Опять-таки, без каких-либо дополнительных указаний с нашей стороны.
Фасад (Facade)
Раз уж вспомнили о хелпере app() и глобальным объекте App — посмотрим, как их можно использовать: