Laravel-Core:为什么Laravel会多次存储别名? [英] Laravel-Core: Why does Laravel store Aliases multiple times?

问题描述

Laravel在Application.php的核心中确实注册了许多这样的默认实现:

Laravel does in its core in Application.php register a lot of the Default Implementations like this:

'url' => ['Illuminate\Routing\UrlGenerator', 'Illuminate\Contracts\Routing\UrlGenerator'],

实际上会两次调用以下方法

Which will in effekt call the method below two times

public function alias($abstract, $alias)
    {
        $this->aliases[$alias] = $abstract;
    }

在Container->aliases中产生以下值:

"Illuminate\Routing\UrlGenerator" => "url"
"Illuminate\Contracts\Routing\UrlGenerator" => "url"

如果以后再致电: $this->app->alias('url', 'App\Util\Portal\UrlGenerator'); 甚至将其保存在别名数组中的Container中的时间为

If I later call: $this->app->alias('url', 'App\Util\Portal\UrlGenerator'); it even stores it a thrid time in the Container im the alias array:

"App\Util\Portal\UrlGenerator" => "url" 

我的问题:

为什么laravel会全部存储两个或三个而不覆盖它们?存储具体的类应该足够了. 但是，laravel为什么将所有这三个都存储起来?当我现在使用App :: make('url')时，laravel如何分辨要解决的问题? Laravel现在有三种可供选择，一种接口和两种实现.

Why does laravel store them all two or three and not override them? It should be sufficient to store the concrete class. But why does laravel store them all three? How can laravel tell, which one to resolve, when I now use App::make('url')? Laravel has now three to choose from, one interface and two implementations.

推荐答案

在它上睡了一个晚上并在代码中进行了更多挖掘(尚未在代码中进行100％验证)后，其最有可能的原因是:

After Sleeping a night over it and digging more in the code (could yet not be 100% verified in code yet) its most likely as that:

别名"

以各种方式/方法使用:

Is used in various ways/methods:

1. 它可以表示Facade的别名(例如FacadeClass的URL).哪一个完全不同(！?)
2. 这可能意味着将所谓的抽象"(术语/字符串)(例如"url")映射到别名"，而在laravel术语中，别名就是类or(！)接口. 别名(如上述方法所做的那样)并不需要直接对绑定进行任何操作.

1. It can mean alias a Facade (like URL to a FacadeClass). Which is something completely different(!?)
2. It can mean mapping a so called "abstract" (term/string) like "url" to an "alias" which in laravel terms is then a class or(!) interface. Aliasing (as the method does above) does NOT directly have to do anything with binding.

绑定"

Laravel容器在其Container类中有两个属性，分别为$aliases和$bindings..绑定将抽象"的实际绑定绑定到实例化的具体类上！ 因此，每个别名(如上所述)都还必须从抽象"要实例化的具体类中也具有一个相应的绑定(！).

Laravel Container has two properties in its Container class named $aliases and $bindings. Bindings hold the real binding of an "abstract" to a concrete class to instanciate! So every alias (as discribed above) needs to also(!) have a corresponding binding(!) from the "abstract" the concrete class to be instanciated.

结论

实际上，如上所述，键/抽象"URL"具有(具体类和接口的)别名.但是他们有 与激励过程无关.为了使别名正常工作，还需要进行真正的绑定！

In effect as written above, there are thre aliases (of concrete classes and interfaces) to the key/abstract "url". But they have nothing to do with the instanciating process. For the alias to work there additinally also needs to be a real binding!

因此，实际上，容器别名"使您可以访问具有其他类或接口名称的现有绑定.

So in effect "Container Aliases" allow you to access an existing binding with other classses or interface names.

1. 如果您使用任何别名调用Container::make()，laravel都会尝试将其解析为抽象"(此处为"url").
2. 然后在第二步中，尝试对这个抽象的"url"进行解析以解决绑定问题(这是完全不同的东西).
3. 如果未找到别名的绑定，则会引发错误.

1. If you call Container::make() with any of the aliases, laravel will try to resolve them to the "abstract" (here "url").
2. And then in a second step, this abstract "url" is then tried to resolve against the bindings (which is something completely different).
3. If no binding is found for the alias, an error is thrown.

因此，您可以具有任意数量的别名，但只有一个绑定，并且您必须具有单个绑定(另外！).

(有趣的是，如果将别名映射到与绑定相同的类，则它似乎以递归错误结尾.但这也可能是 xdebug问题).

(Interestingly, if you map an alias to the same class as the binding, it seems to end in an recursion error. But this also might be an xdebug problem).

这篇关于Laravel-Core:为什么Laravel会多次存储别名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！