Фасады (facade) в Laravel. Что это и для чего используются

[@agajanakmyradow3777]

CutCode вы лучшие)

[@ДарьяШу-п7щ]

Спасибо ❤

[@deen812x]

Отличный ролик. Спасибо

[@CutCodeRu]

🔥

[@nmikser]

Привет! А подскажи пожалуйста, в чем плюс использовать фасады если я просто могу создать классы/сервисы/экшены с статическими методами и просто вызывать их так же как фасад?

[@CutCodeRu]

Привет, ответил в telegram чате

[@0kkama]

@@CutCodeRu хде, в каком разделе? Чет не нашел

[@NuChamu]

Так а какое преимущество?! Почему нельзя просто использовать объекты?

[@АнтонПчёлкин-с1п]

Несколько замечаний: 1) Не помню, с какой версии лары это возможно. Если класс, к которому идет обращение через фасад, не требует каких-то параметров конструктора, можно вообще не писать никакого кода инициализации. Например, написали класс репозиторий какой-нибудь (UsersRepo), создали класс фасада, где в getFacadeAccessor просто пишем return UserRepo::class - и все, не нужно ничего писать в сервис провайдерах. К тому же: 2) Механизм фасадов самостоятельно создает синглтон из класса, который будет передан в getFacadeAccessor без необходимости указывания это в сервис провайдере. 3) Для дополнительного удобства можно прописать алиас для фасада, тогда к нему можно будет напрямую обращаться в тинкере, например

[@CutCodeRu]

Есть еще динамические фасады, что я вообще считаю ужасным явлением и стараюсь наличие их игнорировать, как и тот факт что без сервис контейнера создается фасад хотя в документации и описании концепции они в первом же абзаце пишут Facades provide a "static" interface to classes that are available in the application's service container. и Laravel facades serve as "static proxies" to underlying classes in the service container

[@topalek]

Чёт не вижу ссылки на видео по DOCBLOCK

[@CutCodeRu]

Спасибо что заметили! Добавил в описание и дублирую вам - kzbin.info/www/bejne/kGazh56IeNqSjdk

[@zapasnoy2-s4k]

Мне кажется фасады плохи тем, что они жестко завязаны на работе фреймворка. Я бы рассматривал их на уровне кода приложения, но не бизнес логики.

[@CutCodeRu]

Есть такое дело

[@zlodes01]

Поэтому нужно использовать нормальный DI, так хотя бы Unit-тест нормальный на класс можно будет написать.

[@milanzhelnov8393]

Отличный ролик. Спасибо Вопрос по Service Container. Почему используется для биндинга экземпляра класса Telegram метод ->instance, вместо singleton() ? Ведь, в целом, если у нас один токен на все приложение, то не лучше будет сделать синглтон и всегда его цеплять ? или здесь специально было так задумано на каждый жизненный запрос в контейнер добавлять Telegram::class

[@CutCodeRu]

Я для ролика быстро создал бинд чтобы продемонстрировать фасад)

[@trvtrv3172]

А обязательно ли писать свои фасады для работы?

[@CutCodeRu]

Нет

[@0kkama]

О, спасибо! Еще одна вещь, которую я ненавижу в Ларе)

[@CutCodeRu]

А что ж спасибо тогда?!)

[@0kkama]

@@CutCodeRu ну мне же приходится с этим работать. Буду чуть лучше знать своего врага)

[@trvtrv3172]

Хыхыхы сколько ларавел изучаю не понимал до конца что такое фасады

[@CutCodeRu]

ну теперь то понял?

[@trvtrv3172]

@@CutCodeRu i guess

[@trvtrv3172]

@@CutCodeRu Прочитал доку + посмотрел видео и понял

[@ДмитрийЕгорычев-д9ъ]

Очень разочарован этим видео. Сначала дико резануло, что фасады в Ларе не имеют ничего общего с одноименном паттерном, а это совершенно не так, а по ходу так и не понял, чем они лучше использования обычных классов и чем хуже. Из 10 мин было сказано: "-" (проблемы с SOLID, без доков ничего не подсвечивается); "+" (удобно использовать и тестировать). Поэтому поделюсь своим мнением о фасадах. Самый большой минус - супер неявная зависимость. Когда в каком-то месте у вас появляется Mail::send() ваш код становится зависимым, но это нигде не выражается. Если при обычной инъекции через сервис контейнер это можно отследить через параметры метода/конструктора, то в данном случае зависимость неочевидна. Это может привести к печальным последствиям. Самый большой плюс, собственно и почему стоит использовать/создавать фасады - это простой доступ к сложной системе (то есть сама суть паттерна фасад, для примера можно посмотреть на фасад Mail и его не статический класс Mailer). То есть у вас есть супер крутой, навороченный класс, который объединяет в себе множество других компонентов, выполняет целую кучу сложных действий, но вам не надо предоставлять все это конечному пользователю, ему нужно дать лишь обертку этого класса с доступом к нескольким основным функциям. При этом вы можете менять свой основной класс, как вам нужно, но для конечного пользователя это не важно, так как он использует обертку. Обычно фасады делают для библиотек, чтобы можно было удобно с ними работать, при этом скрыть, что под капотом. А если у вас простой класс в 200 строк, то нет никакого смысла писать под него фасад. UPD: забыл еще дописать, как вы думаете, что будет, если по ошибке забиндить два разных фасада с одним ключом в сервис контейнере?)

[@CutCodeRu]

Спасибо за развернутый комментарий но все же фасады в ларавел это не паттерн фасад, он может им быть в некоторых случаях но по своей концепции это далеко не фасад паттерн, я бы скорее назвал это аксессуаром для сервис контейнера! Да множество классов в ларавел реализует фасад паттерн и обвернут фасадом ларавел но сама концепция и обвертка по своей натуре может ничего общего с этим не иметь! Мы говорим о концепции а не о чем то определенном под каким-либо фасадом как тот пример с Mail что вы приводите. И даже если вы прочитаете документацию то увидите простую истину "Facades provide a "static" interface to classes that are available in the application's service container." ... Laravel facades serve as "static proxies" to underlying classes in the service container и я могу использовать Laravel фасады как обвертку над простыми реализациями ничего общего с фасадами не имеющими но в рамках сервис контейнера вместо DI!

[@CutCodeRu]

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

[@kalobyte]

что-то вообще нихера не понял в этот раз смотрю ролик как баран на ворота сегодня походу день, когда код не заходит совсем

[@CutCodeRu]

Давай попробуем увидится завтра)