何时使用动作注入以及何时为控制器的构造函数注入依赖项？答案

【问题标题】：When to use action injection and when to inject dependencies on the constructor for controllers?何时使用动作注入以及何时为控制器的构造函数注入依赖项？
【发布时间】：2021-07-07 13:23:01
【问题描述】：

在 Symfony 中，您可以直接将服务注入到控制器函数中：

use App\Service\FooService;

class FooController
{
    public function one(FooService $fooService){
        $fooService->doSomething();
    }
}

我正在寻找何时注射和何时不注射的原因/指南。一个或优点/缺点的性能价格是多少，例如：

您必须始终力争没有__construct()吗？
如果一个类中的所有方法都使用FooService，我是仍然在每个方法中加载它们，还是现在使用__construct？

我如何决定实施哪种解决方案？

我目前的逻辑是“尽可能多地使用动作注入，因为这可以节省初始化所有控制器的时间，但缺点是方法调用会慢一点，因为现在必须在那里完成”

_{我认为这个主题处于 SO 允许范围的边缘，我正在寻找指导规则集，而不是评论或意见。}

【问题讨论】：

我正在寻找一个“严格”的规则集，这就是问题所在 - 谁拥有适用于所有开发的如此严格的规则集。大多数人会有家规和自己的个人想法。
当您在方法中注入依赖项时，您并没有将行为抽象与具体依赖项区分开来。依赖于抽象，因此您不会与类依赖项的依赖项耦合。
我已经更改了“严格”这个词，这很有帮助。
@Martijn，在底部，您仍然有一个相互矛盾的问题：我正在寻找指导规则集，而不是评论或意见。 我想我们所有人都会只是给你我们的意见。
考虑在Reddit Symfony forum 上发帖。对此进行了较早的讨论，但我似乎找不到。动作注入用于节省一些样板代码（与构造函数注入相比），但这种类型的 PHP 8 的构造函数提升东西消失了。我自己倾向于使用构造函数注入只是出于习惯。但这真的取决于个人喜好。

标签： php symfony dependency-injection

【解决方案1】：

在这两种情况下都没有显着的性能或内存优势，注入的服务是引用，而不是新实例。

在任何情况下，大多数现代设计都不会有具有多种不同方法的控制器。如果同一个类的许多公共方法有非常不同的依赖关系，也许所有这些方法一开始就不属于同一个类？

最后，这些设计差异是一种风格选择。如今，构造函数注入往往是首选（至少在我身边），因为由于依赖项是类需要在有效声明中才能工作的东西，因此在实例化时传递它们似乎更多对许多人来说是合乎逻辑的。

在许多情况下将其作为方法参数传递并没有本质上的错误（就像将任何其他类型的 callables 作为参数一样），但我认为最好将控制器操作视为任何其他方法：

该方法如何读取更清晰？
方法消费者是否需要知道类依赖关系，并在调用时更改依赖关系，或者这超出了消费者的职责范围？

【讨论】：