Laravel. Сервисы, контракты и внедрение зависимостей
Вставка
- Опубліковано 4 жов 2024
- Как Laravel внедряет зависимости от сервисов и разрешает связи между интерфейсами конкретными классами.
✅ Instagram: / lectoria.pro
✅ VK: lectoria
✅ Facebook: lectori...
✅ Сайт проекта Lectoria: lectoria.pro?Kr32QFDso0
🖥 Обучение веб-разработке Lectoria: / @lectoria
🖥 Обучение разработке на MODX Revolution: / openmodx
Третий день смотрю видео про внедрение зависимостей, куча "обучателей" пытаясь объяснять на примерах с животными, фигурами, машинами пытающимися объяснить не могли донести до меня то что я не понимал, а тут посмотрел ваш ролик и все вопросы которые были в голове отпали. Я в шоке)
Класс. Объяснено лучше чем в платных курсах.
Просто супер! Я столько видео не смотрел, не видел такие чёткие объяснения. Только с вас попрошу снять видео как разделить проект на ларавель по папкам без папки app. Что бы сами смогли создавать свои разные app папки с контроллерами, с моделями и т.д
Так просто создавайте любую другую папку (не app), просто везде учитывайте новое пространство имен и пути к каталогам. Я, правда, такого не делал, но по идее все должно работать, так как стандарт автозагрузки с учетом пространства имен должен корректно отрабатывать. Почитайте про PSR-4 стандарт (по-моему, там как раз описан процесс автозагрузки файлов).
Шикарно , если будет курс по ларавелу , я ваш ученик!
Подробно, интересно, без воды. Спасибо большое !
Спасибо за понятное объяснение!
Без воды, все ясно и понятно. Спасибо!
Спасибо за ваш труд. Было интересно и познавательно.
Толково и понятно. Пожалуй самое доходчивое объяснение как работает DI в Ларавеле. Лайк, подписка (с) Успехов тебе с каналом!
Спасибо, получилось познавательно. Как вы находите время и работать и разбираться в чем-то новом и еще снимать видео, а это ведь тоже труд.
Да на самом деле, все происходит как-то само собой ) Нравится кодить, нравится разбираться, нравится записывать видео. Мне кажется, моя особенность - это разбираться в чем-то до деталей и доносить это в формате видео-уроков другим разработчикам. Аудитория, конечно, небольшая, но, мне кажется, что не так важно обрести огромную аудиторию, сколько донести детали хотя бы небольшому кругу веб-разработчиков. И вот те, кто эти детали улавливает, те и на одной волне со мной )
@@lectoria не останавливайтесь, это действительно интересно. Бывает, что люди знают много, но совершенно не способны рассказать и научить а у вас хорошо получается.
Спасибо работаю на Ларе давно, и было интересно послушать
Классный урок! Спасибо
Спасибо за подробное обьсянение. Все понятно и доступно. Единственное пожелание используйте среду разработки для создания классов и интерфейсов.
Четко и понятно.
На "видтх" чуть не прослезился. Такое тёплое сердцу произношение)
😂
Спасибо!
Красиво 👍.
Спасибо за полезную информацию! 👍 Подписалась)
Отличный урок, спасибо! Такой вопрос: в данный момент ищу пути уменьшения связонности между сервисам, потому что сталкиваюсь с тем, что сервис А зависит от сервиса Б. Конечно, DI можно использовать внутри нужного сервиса и через контейнер создавать инстанс нужного сервиса, который подгрузит нужные зависимости. Но тут мне кажется, что это не совсем правильно, ибо появляется явная зависимость одного сервиса от другого. В той же архитектуре porto представлены Actions, SubActions и Tasks, которые декомпозируют модуль на более мелкие подмодули и там не происходит вызов модулей верхнего уровня модулями его уровня либо уровнем ниже. В общем, что думаете по поводу ситуации, когда сервису необходим другой сервис для выполнения бизнес логики? Будет ли со временем такой подход приносить проблем? Спасибо
Сервисы и классы так или иначе будут зависеть друг от друга. На мой взгляд, чтобы снизить такую зависимость, необходимо абстрагироваться от конкретной реализации и описывать взаимодействие при помощи интерфейсов.
Предположим, класс A нуждается в услугах класса B. Класс A реализован вами, а класс B - вообще чужой и вы в нем ничего менять не можете. В таком случае, как мне кажется, необходимо описать интерфейс C, при помощи которого класс A будет получать услуги класса B (или других аналогичных классов) и реализовать некоторый класс-адаптер, который адаптирует услуги класса B к интерфейсу C.
В итоге, класс A никак не связан с классом B напрямую. Если на каком-то из этапов развития проекта класс B будет заменен на класс D, то вам необходимо написать адаптер, реализующий интерфейс C и класс A даже не узнает об этом.
Звучит сложно, но это первое наиболее очевидное решение, которое пришло в голову :) Будет занимать немного больше времени на этапе реализации, но, верится мне, что при замене класса B, не потребует изменений в классе A.
Почему все так хвалят DIС , но мало кто рассказывает про его недостатки..
Полезно, спасибо
расскажешь про паспорт и то как правильно микромоноилты делать?
Как в laravel (стандартными методами) реализовать RBAC как в Yii2?
Если честно, как оно реализовано в Yii2, я уже не помню, так как последний раз работал с этим фреймворком году в 2014-15м.
А вообще, если говорить о реализации RBAC в Laravel, то там для этих целей хорошо подходят политики и гейты. А роли пользователя можно реализовать различными способами. Например, можно создать таблицу roles и user_roles. Определив, соответственно, роли и их привязки к пользователям. А затем в политике делать проверку на ту или иную роль и в зависимости от этого давать или не давать доступ к определенному функционалу. Посмотрите, у меня на канале есть ролик про гейты политики.
А почему нет информации о \"статичных" вызовов любого кастомного сервиса ?
Смотря что вы имеете ввиду под "статичными" вызовами. Если речь идет о вызове статичных методов класса, то вообще не вижу смысла их каким-либо образом обозревать, так как там все очевидно. А если речь о статичном виде обращения к методам сервиса, то это уже тема фасадов, она заслуживает отдельного ролика.
Не до конца понял в каких случаях надо использовать App::make(), а в каких можем создавать экземпляр просто через new
new мы используем непосредственно в сервис-контейнере, когда указываем связь какой-то абстракции с конкретной реализацией. А в других частях приложения мы обращаемся к абстракции через App::make() или через внедрение зависимостей (когда абстрактный сервис передается в качестве аргумента функции контроллера: типа как public function index(VideoHosting $service) {....} )
Есть ролик про Laravel Passport?
С Laravel Passport еще даже не доводилось поработать на реальном проекте. Поэтому про него пока мне нечего показать и рассказать.
Не досмотрел до конца еще, но так на всякий. А если вместо интерфейса использовать абстрактный класс?
Можно вместо интерфейса и абстрактный класс указать. Не важно.
вопрос. что делать, если мне нужно использовать и vimeo и youtube в разных местах? как я понял, мы биндим только одну реализацию.
Если делать обращение к сервису через внедрение зависимостей, то можно использовать контекстное связывание:
В сервис-провайдере делаем так (несколько раз для разных классов контроллеров или каких-либо других сущностей, где используется внедрение зависимости от класса Vimeo или UA-cam):
$this->app->when(Контроллер::class)
->needs(ИнтерфейсСервиса::class)
->give(function () {
return НужныйЭкземплярКласса;
});
И тогда Laravel будет отдавать конкретную реализацию.
В документации Laravel это называется "Контекстное связывание"
@@lectoria я тут подумал ещё, что если реализация разных сервисов в большей части схожа, то лучше использовать абстрактный класс, а не интерфейс, чтобы не дублировать код. это же «законом» не запрещено? 😅
или есть лучшее решение для случая, когда реализация нескольких систем по большей части схожа, но, например, авторизация и аутентификация и ещё 2-3 метода разные?
@@khomaldi Да, верно, можно сервисы объединять не интерфейсом, а абстрактным классом. Но можно и в абстрактный базовом классе реализовать интерфейс, потому что не факт, что где-то в будущем проекта абстрактный класс будет не лишним :)
фонт-фэмили: "ну нито (("
Отличное видео. На ютубе много пересказов документации, но вот таких более продвинутых вещей дефицит. По вашему видео вопрос: если ситуация обратная не один сервис реализуемый через интерфейс, который можно подменять, а наоборот, допустим сервис доставки и у него 3-4 поставщика услуг - почта, сдэк и т.д. И нужна возможность выбора какой из них в данной ситуации используем. Например, $service->pochta в другом месте $service->cdek. Подходит в данном случае внедрение зависимостей и как настроить привязку?
Я думаю, тут можно сделать некоторый базовый сервис (назовем его "Менеджер постащиков услуг") , который будет работать с абстрактным поставщиком услуг (например, это может быть просто некоторый интерфейс). А все поставщики услуг будут уже реализовывать этот интерфейс. Таким образом классу-менеджеру будет без разницы, с каким конкретно поставщиком услуг он работает. И как раз этот класс-менеджер будет лежать в сервис-контейнере ларавел. Чем-то немного похоже на паттерн "Фабричный метод", но не совсем оно: refactoring.guru/ru/design-patterns/factory-method/php/example
@@lectoria Спасибо!
А будет что нибудь про react / vue ?
Очень хороший вопрос! Обязательно будет, но только сроки пока не могу даже приблизительные сказать.
я бы еще рекомендовал попробовать laravel-livewire
зачем писать каждый раз
Можно мысль более развернуто расписать? Не совсем понял, о чем конкретно речь
@@lectoria если в название файла написать welcome.blade.php, то внутри файла не нужно открывать, закрывать php код.
@@TIM1_89 А я как-то даже и не задумывался над этим )) Спасибо
Не правильно выбрано имя интерфейса. Интерфейс должен был называться как VideoService
а не удобнее ли было бы сделать так:
создаем директорию Services
в ней размещаемVideoHosting.php
тут же создаем директорию Video
в ней размещаем UA-cam.php, Vimeo.php и т.д.
Все в одном месте.
Просто мне не совсем понятно, зачем размещать файлы в на столько разные места...
Или все сервисы и контракты должны строго находиться в одной директории?
Нет, здесь нет строгих требований по размещению файлов. Каждый разработчик волен использовать собственную логику организации, поэтому, если вам удобнее так, как вы описали, то используйте ваш подход.
@@lectoria Спасибо за оперативный ответ!