在控制器类中注入容器

我正在将我的应用程序从 Slim/3 迁移到 Slim/4。也许我很困惑，因为同样的东西有无穷无尽的语法，但我编写了这个：

use DIContainer;
use SlimFactoryAppFactory;
use SlimPsr7Request;
use SlimPsr7Response;
require dirname(__DIR__) . '/vendor/autoload.php';
class Config extends Container
{
}
class Foo
{
protected $config;
public function __construct(Config $config)
{
$this->config = $config;
}
public function __invoke(Request $request, Response $response, array $args): Response {
var_dump($this->config->get('pi'));
return $response;
}
}
$config = new Config();
$config->set('pi', M_PI);
var_dump($config->get('pi'));
AppFactory::setContainer($config);
$app = AppFactory::create();
$app->get('/', Foo::class);
$app->run();

。它没有按预期工作，因为我得到了两个完全不同的容器实例(通过在DIContainer::__construct()中设置断点进行验证)：

我用$config = new Config();创造自己的那个.
一个在$app->run();自动创建，然后作为参数传递给Foo::__construct()。

我做错了什么？

容器尝试解析(并创建)DIContainer类的新实例，因为这不是 Slim 使用的接口。相反，请尝试声明 PSR-11ContainerInterface。然后，DIC 应传递正确的容器实例。

例

use PsrHttpMessageServerRequestInterface;
public function __construct(ContainerInterface $container)
{
$this->container = $container;
}

相同的"规则"适用于请求处理程序接口。

完整示例：

use PsrContainerContainerInterface;
use PsrHttpMessageResponseInterface as Response;
use PsrHttpMessageServerRequestInterface as Request;
class Foo
{
private $container;
public function __construct(ContainerInterface $container)
{
$this->container = $container;
}
public function __invoke(
Request $request,
Response $response,
array $args = []
): Response {
var_dump($this->container);
}
}

最后一点：注入容器是一种反模式。请改为在构造函数中显式声明所有类依赖项。

为什么注入容器(在大多数情况下)是一种反模式？

在 Slim 3 中，"服务定位器"(反模式)是注入整个(Pimple)容器并从中获取依赖项的默认"样式"。

服务定位器(反模式)隐藏了类的真正依赖项。

服务定位器(反模式)也违反了 SOLID 的控制反转 (IoC) 原则。

问：我怎样才能让它变得更好？

答：使用composition和(显式)构造函数依赖项注入。

依赖注入是一种编程实践，它传递给一个对象，它是协作者，而不是对象本身创建它们。

从Slim 4开始，您可以使用现代DICPHP-DI和league/container具有令人敬畏的"自动接线"功能。这意味着：现在您可以在构造函数中显式声明所有依赖项，并让 DIC 为您注入这些依赖项。

更明确地说："构图"与DIC的"自动连线"功能无关。您可以将组合与纯类一起使用，而无需容器或其他任何内容。自动连线功能仅使用 PHP 反射类自动解析和注入依赖项。

这是 PHP-DI 自动注册自身方式的结果。在撰写此答案时，PHP-DI 容器会在创建时自动将自身注册到密钥DIContainer以及三个实现的接口(请参阅容器.php的这些行)。因此，如果您针对DIContainer或其实现的三个接口之一(包括PsrContainerContainerInterface)键入提示构造函数参数，PHP-DI 能够自行解析。

ُ问题是使用self::class(该文件的第 110 行)使DIContainer密钥以某种方式硬编码，因此尽管您正在创建一个DIContainer(Config) 的子类，容器仍然注册到与以前相同的密钥。解决此问题的一种方法是让容器知道Config也应自行解析。我看到两个选项：

将容器注册到与其类名相同的键，就像DIContainer所做的那样(这似乎是正确的方法)
实例化容器后手动注册容器

这是一个完全工作的示例：

<?php
require '../vendor/autoload.php';
use DIContainer;
use SlimFactoryAppFactory;
use PsrContainerContainerInterface;
use DIDefinitionSourceMutableDefinitionSource;
use DIProxyProxyFactory;
class Config extends Container
{
public function __construct(
MutableDefinitionSource $definitionSource = null,
ProxyFactory $proxyFactory = null,
ContainerInterface $wrapperContainer = null
) {
parent::__construct($definitionSource, $proxyFactory, $wrapperContainer);
// Register the container to a key with current class name
$this->set(static::class, $this);
}
}
class Foo
{
public function __construct(Config $config)
{
die($config->get('custom-key'));
}
}
$config = new Config();
$config->set('custom-key', 'Child container can resolve itself now');
// Another option is to not change Config constructor,
// but manually register the container in intself with new class name
//$config->set(Config::class, $config);
AppFactory::setContainer($config);
$app = AppFactory::create();
$app->get('/', Foo::class);
$app->run();

请注意：正如最佳实践所建议的那样，您不应该针对具体类(DIContainer或您的Config类)键入提示，而应该考虑针对接口(PsrContainerContainerInterface)进行类型提示。

问题是滥用了称为自动布线的 PHP-DI 功能：

自动布线是一个异国情调的词，代表非常简单的东西：容器自动创建和注入的能力依赖。
为了实现这一点，PHP-DI 使用 PHP 的反射来检测什么构造函数需要的参数。

如果使用工厂方法创建容器，则可以禁用自动连线，并且"奇怪"行为将停止：

$builder = new ContainerBuilder(Config::class);
$builder->useAutowiring(false);
$config = $builder->build();

但我想更好的解决方案是学习如何正确使用自动布线:)

我忽略了所有这些细节，因为我的代码最初是为 Slim/3 编写的，它使用 Pimple 作为

~~硬编码的默认~~容器。我错误地认为它们会类似地工作，但是，尽管是容器解决方案，但这两个库却完全不同。

相关内容

最新更新

热门标签：