拉拉维尔的服务提供商和国际奥委会


Service Providers and IoC in 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"
    ];
}

我对几件事有些困惑:

  1. 为什么provides函数(特别是"chat.server")中的字符串与register函数中绑定的内容不匹配?提供不是有必要告诉什么IoC什么是可用的,什么是将绑定的吗?

  2. 当某物被app绑定时,用于绑定它的字符串的约定是什么?例如,在上面的代码中,"chat.emitter"返回一个EventEmitter,但类EventEmitter与聊天文件夹无关。事实上,它位于Evenement包中。此外,"聊天"不是 namspace 的顶部,Formativ是。为什么不是"formativ.chat.user"?那么,这里的标准是什么?那根绳子的每一段是什么意思?

为什么 provision 函数(特别是"chat.server")中的字符串与注册函数中绑定的内容不匹配?提供不是有必要告诉什么 IoC 什么是可用的,什么将被绑定?

看起来像教程中的错误/拼写错误。FWIW,用户和服务器(chat.user/chat.server - 不匹配的提供程序)在快速编写时很容易交换。

当应用绑定某些内容时,用于绑定它的字符串的约定是什么?

没有。 这些服务提供商旨在成为服务的全局(如整个世界)标识符。 没有强制的命名约定,而且从我所看到的情况来看,Laravel是一个足够小/孤立的社区,这不是一个主要问题。 如果我要重新分发服务提供商,我会使用类似

companyname_servicename

companyname部分是我的公司/项目的唯一命名空间,servicename标识服务的功能。 虽然在避免命名空间冲突方面不是 100% 确定性的,但这将确保人们需要不遗余力地选择一个与我的名字冲突的名称。

您无法从服务名称派生有关基础类的任何内容 - 即使可以,IoC 容器的全部意义在于让用户根据需要交换不同的实现。这意味着即使您可以从服务名称派生类名,您也不知道其他开发人员和/或第三方包做了什么。

希望对您有所帮助!