Laravel IOC 绑定 - 关闭与自动解析答案

【问题标题】：Laravel IOC binding - closure vs. automatic resolutionLaravel IOC 绑定 - 关闭与自动解析
【发布时间】：2014-06-16 11:37:47
【问题描述】：

我有一个关于 Laravel 的 IOC 绑定的问题，尤其是注册 Facade 访问器的服务提供者。

遵循IOC的官方文档

class FooServiceProvider extends ServiceProvider {

    public function register()
    {
        $this->app->bind('foo', function()
        {
            return new \MyApp\Foo;
        });
    }

}

以后你可以有一个 Facade，它只返回“foo”作为“FacadeAccessor”。

这样重写这段代码不是更容易吗？

class FooServiceProvider extends ServiceProvider {

    public function register()
    {
        $this->app->bind('foo', '\MyApp\Foo');
    }

}

它给出了几乎相同的结果，因为字符串将自动包装到 Closure 中并通过 App::make() 解析。不仅如此 - 如果需要，Foo 构造函数可以进行依赖注入（据我所知，在第一种情况下您必须传递确切的对象，并且松散的自动解析）。

第二个选项看起来更简洁，除非您在对象初始化之前需要一些额外的逻辑——比如传递数据、初始化其他服务/对象等——对我来说看起来更好。

也许存在与此相关的性能问题？还是我错过了其他东西？

有趣的事实 - 在文档中，对于接口，Laravel 建议第二个选项而不是闭包，但对于 ServiceProviders - 直接对象初始化。

【问题讨论】：

你的问题是什么？
如果你使用第二种方法，当两个类相互依赖时，你可能会陷入无限循环。您创建 A 类，然后它尝试创建 B 类，但 B 类需要 A 类，因此它会尝试再次创建它，依此类推。
还因为与依赖注入这样的依赖注入相比，通常需要做更多的自定义操作。
@Robbo - 您适合自定义绑定。但是对于 Facades（稍后），通常只是简单的类初始化。
@WereWolf-TheAlpha - 我的问题是：使用第二个选项是否有任何潜在/可能的问题。 Robbo 已经回答了无限循环 - 这是正确的，但这取决于可能的应用程序架构问题。

标签： php laravel inversion-of-control bind service-provider

【解决方案1】：

第二个选项是最好的，闭包主要用于给出做某事的方式的一个很好的快速示例。

我个人避免关闭，除了路由，因为我希望 IoC 容器可以在需要时运行各种不同的依赖注入。

【讨论】：