Есть ли смысл создавать собственные сервис-провайдеры в рамках одного проекта?
Допустим, есть некий проект, в рамках которого, скажем, будет вестись работа с неким внешним API (или что-то в этом духе, неважно, просто какой-то относительно обособленный кусок функционала).
Есть ли смысл оформлять этот функционал именно в виде сервис-провайдера?
И если да - то какой?
Или просто классом оставить и подключать как обычно.
В чем вообще прикол этих сервис-провайдеров, коли и без этого можно все делать и все будет хорошо и удобно.
Простыми словами или на примере ответьте пожалуйста :)
Лучший вариант — описать все зависимости класса в одном месте и предоставить фреймворку их подготовку (у зависимостей ещё и свои зависимости могут быть). Для этого и нужен провайдер.
Для среднего проекта вполне хватает AppServiceProvider, если вы не пурист.
Но, судя по вопросу, кажется, вы смешали между собой какие-то сущности. Провайдер используется для регистрации вашего класса в DI-контейнере. Использовать DI-контейнер по сравнению с new Class удобнее.
Использовать DI-контейнер по сравнению с new Class удобнее.
А в чем именно удобство?
Алексей, я хочу понять, с какой целью вообще городят этот огород ))
В моем понимании, если делаются какие-то лишние телодвижения, то они должны себя как-то окупать в будущем, либо упрощать расширяемость, либо что-то еще такое.
Имеет ли смысл интегрировать класс в качестве сервис-провадера? (php artisan make:provider и т.п.?)
Ещё раз — вы путаете. Ваш класс и сервис-провайдер — это две разные сущности. Создавать провайдер не нужно, можно использовать стандартный. Регистрировать свой класс в стандартном провайдере имеет смысл.
Зачем нужен DI-контейнер поищите, этот вопрос уже очень много раз объяснён в самых разных видах, нет смысла повторяться.