Есть ли смысл создавать собственные сервис-провайдеры в рамках одного проекта?

Question

[Роми]

Допустим, есть некий проект, в рамках которого, скажем, будет вестись работа с неким внешним API (или что-то в этом духе, неважно, просто какой-то относительно обособленный кусок функционала).

Есть ли смысл оформлять этот функционал именно в виде сервис-провайдера?

И если да - то какой?

Или просто классом оставить и подключать как обычно.

В чем вообще прикол этих сервис-провайдеров, коли и без этого можно все делать и все будет хорошо и удобно.

Простыми словами или на примере ответьте пожалуйста :)

Comments

[JhaoDa]

«как обычно» это как?

[FanatPHP]

Мне нравится эта незамутнённость, "что у меня за проект - это неважно, но вы мне нарисуйте пример обязательно конкретный!"

[Роми]

JhaoDa,

use Services\SomeServ;

...

public function pfunc(SomeServ $ss)
 {
$ss->method();

...

[Роми]

FanatPHP, ну не рисуйте ))

[JhaoDa]

Роми, допустим, для API нужный логин-пароль. Как в твоём варианте их в этот SomeServ передать?

[Роми]

JhaoDa, это зависит от контекста, но обычно я делаю через конструктор, т.е. примерно так это было бы:

...

public function pfunc()
 {
$ss = new SomeServ($login,$pass);
$ss->method();

...

[Роми]

...т.е .тут всякие вариации на эту тему возможны)) по ситуации, в зависимости от того, надо ли менять парамерты и пр., но обычно так как выше.

Есть лучшие варианты? :)

[Алексей Уколов]

Лучший вариант — описать все зависимости класса в одном месте и предоставить фреймворку их подготовку (у зависимостей ещё и свои зависимости могут быть). Для этого и нужен провайдер.

[JhaoDa]

Роми, сдаётся мне, ты документацию читал по диагонали...

[Роми]

JhaoDa, а как надо, учить наизусть все подряд?

[Роми]

Алексей Уколов, спасибо. Этот тезис надо осмыслить ))

Answer 1

[Алексей Уколов]

Для среднего проекта вполне хватает AppServiceProvider, если вы не пурист.

Но, судя по вопросу, кажется, вы смешали между собой какие-то сущности. Провайдер используется для регистрации вашего класса в DI-контейнере. Использовать DI-контейнер по сравнению с new Class удобнее.

Comments

[Роми]

Использовать DI-контейнер по сравнению с new Class удобнее.

А в чем именно удобство?

Алексей, я хочу понять, с какой целью вообще городят этот огород ))

В моем понимании, если делаются какие-то лишние телодвижения, то они должны себя как-то окупать в будущем, либо упрощать расширяемость, либо что-то еще такое.

Имеет ли смысл интегрировать класс в качестве сервис-провадера? (php artisan make:provider и т.п.?)

[Алексей Уколов]

Ещё раз — вы путаете. Ваш класс и сервис-провайдер — это две разные сущности. Создавать провайдер не нужно, можно использовать стандартный. Регистрировать свой класс в стандартном провайдере имеет смысл.
Зачем нужен DI-контейнер поищите, этот вопрос уже очень много раз объяснён в самых разных видах, нет смысла повторяться.

[Роми]

Алексей Уколов, я не понимаю.

Ладно, проехали)) спасибо и на этом

[Алексей Уколов]

Ну так почитайте статьи, их сотни. Там есть объяснения, есть примеры.

[Роми]

Алексей Уколов, в статьях описано КАК, но не описано ЗАЧЕМ.

[Алексей Уколов]

Ну что вы мне рассказываете? Первая же ссылка в гугле: https://m.habr.com/ru/post/350708/

[Роми]

Алексей Уколов, хороший цикл статей. Прочитаю ) Спасибо!