Laravel. Сервисы, контракты и внедрение зависимостей 

Так просто создавайте любую другую папку (не app), просто везде учитывайте новое пространство имен и пути к каталогам. Я, правда, такого не делал, но по идее все должно работать, так как стандарт автозагрузки с учетом пространства имен должен корректно отрабатывать. Почитайте про PSR-4 стандарт (по-моему, там как раз описан процесс автозагрузки файлов).

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

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

😂

Сервисы и классы так или иначе будут зависеть друг от друга. На мой взгляд, чтобы снизить такую зависимость, необходимо абстрагироваться от конкретной реализации и описывать взаимодействие при помощи интерфейсов. Предположим, класс A нуждается в услугах класса B. Класс A реализован вами, а класс B - вообще чужой и вы в нем ничего менять не можете. В таком случае, как мне кажется, необходимо описать интерфейс C, при помощи которого класс A будет получать услуги класса B (или других аналогичных классов) и реализовать некоторый класс-адаптер, который адаптирует услуги класса B к интерфейсу C. В итоге, класс A никак не связан с классом B напрямую. Если на каком-то из этапов развития проекта класс B будет заменен на класс D, то вам необходимо написать адаптер, реализующий интерфейс C и класс A даже не узнает об этом. Звучит сложно, но это первое наиболее очевидное решение, которое пришло в голову :) Будет занимать немного больше времени на этапе реализации, но, верится мне, что при замене класса B, не потребует изменений в классе A.

Если честно, как оно реализовано в Yii2, я уже не помню, так как последний раз работал с этим фреймворком году в 2014-15м. А вообще, если говорить о реализации RBAC в Laravel, то там для этих целей хорошо подходят политики и гейты. А роли пользователя можно реализовать различными способами. Например, можно создать таблицу roles и user_roles. Определив, соответственно, роли и их привязки к пользователям. А затем в политике делать проверку на ту или иную роль и в зависимости от этого давать или не давать доступ к определенному функционалу. Посмотрите, у меня на канале есть ролик про гейты политики.

Смотря что вы имеете ввиду под "статичными" вызовами. Если речь идет о вызове статичных методов класса, то вообще не вижу смысла их каким-либо образом обозревать, так как там все очевидно. А если речь о статичном виде обращения к методам сервиса, то это уже тема фасадов, она заслуживает отдельного ролика.

Если делать обращение к сервису через внедрение зависимостей, то можно использовать контекстное связывание: В сервис-провайдере делаем так (несколько раз для разных классов контроллеров или каких-либо других сущностей, где используется внедрение зависимости от класса Vimeo или RU-vid): $this->app->when(Контроллер::class) ->needs(ИнтерфейсСервиса::class) ->give(function () { return НужныйЭкземплярКласса; }); И тогда Laravel будет отдавать конкретную реализацию. В документации Laravel это называется "Контекстное связывание"

@@lectoria я тут подумал ещё, что если реализация разных сервисов в большей части схожа, то лучше использовать абстрактный класс, а не интерфейс, чтобы не дублировать код. это же «законом» не запрещено? 😅 или есть лучшее решение для случая, когда реализация нескольких систем по большей части схожа, но, например, авторизация и аутентификация и ещё 2-3 метода разные?

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

new мы используем непосредственно в сервис-контейнере, когда указываем связь какой-то абстракции с конкретной реализацией. А в других частях приложения мы обращаемся к абстракции через App::make() или через внедрение зависимостей (когда абстрактный сервис передается в качестве аргумента функции контроллера: типа как public function index(VideoHosting $service) {....} )

Можно вместо интерфейса и абстрактный класс указать. Не важно.

С Laravel Passport еще даже не доводилось поработать на реальном проекте. Поэтому про него пока мне нечего показать и рассказать.

Я думаю, тут можно сделать некоторый базовый сервис (назовем его "Менеджер постащиков услуг") , который будет работать с абстрактным поставщиком услуг (например, это может быть просто некоторый интерфейс). А все поставщики услуг будут уже реализовывать этот интерфейс. Таким образом классу-менеджеру будет без разницы, с каким конкретно поставщиком услуг он работает. И как раз этот класс-менеджер будет лежать в сервис-контейнере ларавел. Чем-то немного похоже на паттерн "Фабричный метод", но не совсем оно: refactoring.guru/ru/design-patterns/factory-method/php/example

@@lectoria Спасибо!

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

я бы еще рекомендовал попробовать laravel-livewire

Можно мысль более развернуто расписать? Не совсем понял, о чем конкретно речь

@@lectoria если в название файла написать welcome.blade.php, то внутри файла не нужно открывать, закрывать php код.

@@TIM1_89 А я как-то даже и не задумывался над этим )) Спасибо

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

@@lectoria Спасибо за оперативный ответ!