Laravel по-русски

Kiran +3

Сообщений: 48

Фасады тонкости.

Добрый день, любителям ларавела :-).

С инглишом не совсем силен, а вот в русских доках совсем не встречал такой инфы. Сейчас создаю фасады просто указывая на мой класс без всякого создание сервис контейнера. Это удобно ибо проще. Но вот в доках везде пишут, что надо создавать сервис контейнер вначале. А вот зачем если он сам создаётся? :-)

constb +141

Мастер

Сообщений: 624

Re: Фасады тонкости.

по-моему ты перепутал сервис-контейнер и сервис-провайдер

сервис-контейнер – это хранилище всех связей (bindings) со всякой всячины на конкретные классы. всячина может быть простыми текстовыми алиасами, именами интерфейсов и прочим, связи могут быть простыми, синглтонами, хитрыми функциями-фабриками объектов со своей логикой работы – много чего он умеет, особенно круто что он может встраивать нужные штуки автоматически, как при создании объекта (app()->make()) так и при вызове метода (app()->call()), обеспечивая dependency injection

сервис-провайдер – это простой класс, основная задача которого – прочитать конфиг нужной штуки (если он есть) и нужным образом зарегистрировать в сервис-контейнере все алиасы и интерфейсы, соответствующие этой штуке. сама штука – это может быть пакет, установленный композером, это может быть какая-то область функционала в приложении (например EventServiceProvider – отвечает за связывание событий и обработчиков в приложении)

надеюсь с терминологией понятно. из неё в целом и вытекает – зачем. в пакете сервис-провайдер как бы «открывает доступ» к апи пакета в приложении и настраивает его в соответствии с конфигом. пакет для отправки почты например узнаёт какой драйвер программист выбрал для выполнения этой отправки – стандартный пхпшный mail или smtp или ещё что-то. теперь когда ты попросишь у сервис-контейнера 'mailer' он по этому алиасу отдаст тебе объект какого-то класса, который будет реализовывать нужный интерфейс и работать именно так как ты указал в настройках. кроме того зарегистрирован он в сервис-контейнере как singleton – то есть на каждое обращение за 'mailer' ты будешь получать один и тот же экземпляр

фасады тут вообще необязательны по сути, я лично предпочитаю всегда получать нужные объекты через dependency injection, а фасады – только когда быстро и грязно хочу что-то закодить и посмотреть что вышло. код с фасадами хоть и можно покрывать тестами, но код с DI – проще, надо всего лишь передать вручную экземпляр мока вместо реального объекта в метод и вуаля, тест пошёл

кроме того с фасадами всё не очень красиво с автокомплитом. да я в курсе про все нужные костыли, но сам в приложении если что-то регистрирую и получаю с сервис-контейнера, предпочитаю использовать функции-хэлперы. например если у меня свой класс корзины App\Services\Cart есть, то я скорее добавлю функцию function cart() { return app()->make(\App\Services\Cart::class); } или зарегистрирую этот класс как синглтон и тогда у меня будет function cart() { return app('cart'); } – но потом я на эту функцию добавлю докблок и у меня автокомплит будет работать и код получится читаемый вида cart()->addProduct($product, $quantity); например. можно и фасадами, но мне там больше по душе

если ты используешь фасады в коде приложения (не в пакете), то регистрировать класс через сервис-контейнер конечно не обязательно. более того – начиная с 5.4 необязательно создавать и фасад, они теперь создаются автоматически, достаточно сделать use Facades\App\Services\Cart; и у меня в файле будет доступен фасад Cart на мой класс, без написания единой строчки кода. на автокомплит конечно тут лучше не расчитывать, пхпшторм наверное вообще с ума сходить от такого будет

Kiran +3

Сообщений: 48

Re: Фасады тонкости.

Спасибо за такой классный ответ. я учусь кодить красиво, но пока опыта мало, поэтому такие ответы очень ценные. Чем больше такой информации попадает тем лучше получается код. Сейчас написал класс для операций вставки обновления и прочего для контроллера и наследую его всеми другими контроллерами, вот там не получается метод внедрить при перегрузке функций... Сейчас все больше и больше ясности приходит по работе с сервис контейнером , поначалу  мозг совсем отказывался понимать :-). А уж грамотная работа с редактором кода для меня конечно это высший пилотаж :-)
Спасибо!