Поставщики услуг и IoC в Laravel

Question

Поставщики услуг и IoC в Laravel

Я прохожу учебник Вот, и я наткнулся на следующий блок кода в ServiceProvider,

public function register()
{
$this->app->bind("chat.emitter", function ()
{
return new EventEmitter();
});
$this->app->bind("chat.chat", function ()
{
return new Chat($this->app->make("chat.emitter"));
});
$this->app->bind("chat.user", function ()
{
return new User();
});
$this->app->bind("chat.command.serve", function ()
{
return new Command\Serve($this->app->make("chat.chat"));
});
$this->commands("chat.command.serve");
}

public function provides()
{
return [
"chat.chat",
"chat.command.serve",
"chat.emitter",
"chat.server"];
}

Я несколько смущен парой вещей:

Почему не строки в provides Функция (в частности, «chat.server») соответствует тому, что связано в register функционировать? Это не обеспечивает, необходимо сказать, что IoC что доступно и что будет связано?
Когда что-то связано appКакое соглашение для строки, используемой, чтобы связать это? Например, в приведенном выше коде «chat.emitter» возвращает EventEmitter, но класс EventEmitter не имеет ничего общего с папкой чата. На самом деле он расположен в Evenement пакет. Кроме того, «чат» не является вершиной пространства, Formativ является. Почему это не «formativ.chat.user»? Итак, какой здесь стандарт? Что означает каждый кусок этой строки?

0

inversion-of-control laravel php service-provider

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Почему строки в функции обеспечивает (в частности, «chat.server») не совпадают с тем, что связано в функции регистра? Разве нет необходимости указывать, какой IoC доступен, а какой будет связан?

Похоже на ошибку / опечатку в учебнике. FWIW, пользователь и сервер (chat.user/chat.server — несоответствующие провайдеры) довольно легко поменять местами, когда вы пишете быстро.

Когда приложение связывает что-либо, каково правило для строки, используемой для его связывания?

Здесь ничего нет. Эти поставщики услуг должны быть глобальными (как и во всем мире) идентификаторами для услуги. Там нет обязательного соглашения об именах, и из того, что я видел, Laravel — небольшое / достаточно изолированное сообщество, что это не было большой проблемой. Если бы я собирался перераспределить поставщика услуг, я бы использовал соглашение об именах что-то вроде

companyname_servicename

companyname часть является уникальным пространством имен для моей компании / проекта, а servicename определить, что сделал сервис. Не будучи на 100% детерминированным во избежание коллизий пространства имен, это было бы убедиться, что люди должны будут изо всех сил выбрать имя, которое будет сталкиваться с моим.

Вы не можете извлечь что-либо о базовом классе из имени службы — даже если бы вы могли, весь смысл контейнера IoC состоит в том, чтобы позволить пользователям менять местами реализации, если они этого хотят. Это означает, что даже если вы можете получить имя класса из имени службы, вы не знаете, что сделал какой-то другой разработчик и / или сторонний пакет.

Надеюсь, это поможет!

1