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