不应将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而不是构造函数。

那么 major 次要警告的原因是什么？

我们更喜欢使用setter而不是将容器作为构造函数中的参数传递（反向）的原因/时间的解释将非常感激。

修改

回应评论：

SLI并不关心如何注射容器，显然注射它是一种不好的做法。

是否有符合SLI标准的替代方案？

Answer 1

感谢@RenatoMendesFigueiredo的帮助，@ hasumedic＆amp; （大部分）@Cerad，不需要高级计划，我可以看到这个警告的要点并弄明白。

事实上，很久以前，我会让我的服务扩展ContainerAware而不是直接编写方法，但是被迫忍受其限制（服务无法扩展另一个类）。

在2.4中，添加了ContainerAwareTrait。

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

1）没有理由编写一个setter或构造函数来注入容器，如果已经存在这样做的特征。

2）无需将容器作为参数传递给另一个目标，而不是将其注入服务。

此外，我从服务类中删除了setContainer方法，使其使用ContainerAwareTrait并保留服务定义。

并且......

<强>奖励！