Symfony依赖注入容器不应作为参数传递

Question

今天早上，SensioLabs Insight从我的一个分发包中删除了白金徽章。

Symfony依赖注入容器不应作为参数传递。

 /** * Sets the Container. * * @param ContainerInterface|null $container */ public function setContainer(ContainerInterface $container = null) 

已找到一个Symfony依赖项注入容器作为参数。

该方法是以下服务的一部分：

rch_jwt_user.credential_fetcher:
    class: RCH\JWTUserBundle\Service\CredentialFetcher
    calls:
        - [ setContainer, [ "@service_container" ] ]

我知道我可以像这样将容器作为构造函数参数传递：

rch_jwt_user.credential_fetcher:
    class: RCH\JWTUserBundle\Service\CredentialFetcher
    arguments: [ "@service_container" ]

但是，许多社区捆绑包使用的是setter而不是构造方法。

那么，这个 重大的 次要警告是什么原因呢？

真正理解为什么/何时应该使用setter而不是将容器作为构造函数中的参数传递的解释（以及相反的解释）。

编辑

回应评论：

SLI并不关心容器的注入方式，显然注入容器是一种不好的做法。

有符合SLI的替代方案的想法吗？

Answer 1

感谢@ RenatoMendesFigueiredo，@ hasumedic和（大部分）@Cerad的帮助，不需要高级计划，我可以看到此警告的要点并加以解决。

实际上，很久以前，我将使我的服务扩展ContainerAware而不是直接编写该方法，而是被迫遵守其限制（该服务不能扩展另一个类）。

在2.4中，添加了ContainerAwareTrait 。

我的猜测是，警告已与此特征同时添加，因为：

1）如果编写容器的特征已经存在，则没有理由编写设置器或构造函数以注入容器。

2）除了将其注入服务之外，无需将容器作为另一个目标的参数传递。

另外，我从服务类中删除了setContainer方法，使其使用ContainerAwareTrait并像以前一样保留了服务定义。

还有...

荣誉 ！