php - MVC和依赖注入(inject)，被迫使用单例Controller？

Question

我正致力于构建一个 PHP 框架，该框架的行为符合 MVC 原则并利用依赖注入(inject)。我想我的前置 Controller 部分已关闭；有一个工作路由器实例化 Controller 实例并根据请求的 URI 调用适当的操作。

接下来是依赖注入(inject)。我想实现一个使用反射解决依赖关系的容器。在这样做时，我认为我的 Controller 遇到了问题。

有许多我称之为“系统依赖项”的东西需要对派生的 Controller 类可用。我实际上还没有创建所有这些依赖项，但 Controller 可以访问像 InputProvider(封装 get/post 参数或命令行参数)和输出依赖项这样的服务似乎是明智的。理想情况下，我会使用框架的容器将这些依赖项注入(inject) Controller 的构造函数中 - 但这是我遇到问题的地方。

如果我对 Controller 中的系统依赖项使用构造函数注入(inject)，那么我将强制派生 Controller 管理基本 Controller 的依赖项(如果它们实现了自己的构造函数)。这似乎不是最人性化的。另一种选择是对系统依赖项使用 setter 注入(inject)，但是如果派生 Controller 在其构造函数中需要这些系统依赖项，则它们将无法访问这些系统依赖项。

我看到的唯一一个两全其美的解决方案是让我的 Controller 成为单例。他们有一个私有(private)构造函数，这样我就可以安全地使用 setter 注入(inject)，而不必担心派生类的构造函数。相反，会有一个可覆盖的 initialize() 方法(假设我让方法注入(inject)以某种方式工作)，它基本上履行了构造函数的角色(如派生 Controller 的初始化程序)。这样，构造函数注入(inject)被 initialize() 方法中的方法注入(inject)所取代，所有系统依赖项都可用，而无需派生 Controller 来管理它们。

但是，快速谷歌搜索似乎一致认为单例 Controller 是不好的做法。我非常不确定如何进行。我可能过度设计了这一点，但除了希望我的应用程序面向 future 和可维护之外，我还认为这是应用最佳实践的一个小练习，所以我想“正确地”做事。
我认为在这种情况下的最佳实践是将管理所需系统依赖项的责任传递给派生 Controller 。如果派生 Controller 确实需要它，则可能只应实例化依赖项。如果派生 Controller 可能永远不会使用它，为什么还要在基础 Controller 中注入(inject) InputProvider 呢？但与此同时，我不断回到用户友好性，以及总是有一个可用的 $this->input 成员是多么美好，例如在像 CodeIgniter 这样的框架中。

我非常感谢对我的难题做出的所有贡献。我也为文字墙道歉，但我想不出任何代码示例可以使解释工作变得更容易，因为现在对我来说一切都太抽象了!

此致，
一个严重撕裂的人

Answer 1

有几种可能的解决方案:

• 禁止 Controller 使用__construct():将其设为private public final，并让 Controller 覆盖类似init()的东西并从构造函数中调用它。然后构造函数将注入(inject)所有依赖项(反射？其他东西？)，以便它们在 init() 中准备就绪。

• 您可以使用现有的 DI 库，例如 PHP-DI (免责声明:我致力于此)这将允许您定义依赖项，但让它们在构造函数中可用(神奇地，是的)。

类似的东西:

<?php
use DI\Annotations\Inject;

class FooController {
    /**
     * @Inject
     * @var Bar
     */
    private $bar;

    public function __construct() {
        // The dependency is already injected
        $this->bar->sayHello();
    }

    public function setBar(Bar $bar) {
        return $this->bar = $bar;
    }
}

例如，这就是我使用 Zend Framework 1 的方式。我不能使用构造函数，所以我注入(inject)到属性中。这是 ZF1 integration project .