TYPO3 FormFinisher并发执行与Extbase依赖注入的最佳实践

在typo3 extbase开发中，自定义formfinisher在处理并发提交时，若采用不当的依赖注入方式，可能导致“too few arguments”错误。本文将深入探讨这一问题，解释其根本原因，并提供基于extbase `@inject` 注解的标准化解决方案，确保在多用户同时操作下应用的稳定性和健壮性。

TYPO3 Extbase自定义FormFinisher中的依赖注入挑战

在TYPO3 CMS的Extbase框架中，开发自定义功能时，我们经常需要引入其他服务或仓库（Repository）。当涉及到自定义FormFinisher并处理并发请求时，一个常见的陷阱是尝试在构造函数中手动实例化依赖项，这可能导致在特定条件下出现“Too few arguments to function TYPO3\CMS\Extbase\Persistence\Repository::__construct()”的错误。

问题描述

假设我们有一个自定义的FormFinisher，其构造函数中通过 GeneralUtility::makeInstance() 方法来获取 PersistenceManager 和一个自定义的 ArticleRepository 实例，代码示例如下：

namespace [NAMESPACE]\[ExtName]\Domain\Finishers;

use TYPO3\CMS\Core\Utility\GeneralUtility;
use TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager;
use [NAMESPACE]\[ExtName]\Domain\Repository\ArticleRepository;
use TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher;

class ImageGalleryFinisher extends AbstractFinisher
{
    /**
     * @var PersistenceManager
     */
    protected $persistenceManager = null;

    /**
     * @var ArticleRepository
     */
    protected $articleRepository = null;

    public function __construct()
    {
        parent::__construct();
        $this->persistenceManager = GeneralUtility::makeInstance(PersistenceManager::class);
        $this->articleRepository = GeneralUtility::makeInstance(ArticleRepository::class);
    }

    // ... 其他Finisher逻辑 ...
}

当多个用户几乎同时（例如，间隔1-5秒）提交表单时，可能会有一个提交者遇到以下错误：

Too few arguments to function TYPO3\CMS\Extbase\Persistence\Repository::__construct(), 0 passed in .../typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 3477 and exactly 1 expected

错误堆栈进一步显示，问题发生在 GeneralUtility::makeInstance() 尝试创建 ArticleRepository 实例时，而 ArticleRepository（作为Extbase Repository的子类）的构造函数期望一个 ObjectManagerInterface 参数。

// TYPO3\CMS\Extbase\Persistence\Repository.php
public function __construct(ObjectManagerInterface $objectManager)
{
    $this->objectManager = $objectManager;
    $this->objectType = ClassNamingUtility::translateRepositoryNameToModelName($this->getRepositoryClassName());
}

问题根源分析

这个问题的核心在于对Extbase依赖注入机制的误解和不当使用。

1. Extbase的依赖注入容器： Extbase框架拥有自己的依赖注入（DI）容器，它负责管理Extbase组件（如Controller、Service、Repository等）的生命周期和依赖关系。当Extbase实例化一个对象时，它会检查该对象的所有依赖项，并自动将它们注入到构造函数或通过setter方法注入。
2. Repository 构造函数的期望： 所有的Extbase Repository 类都期望在构造函数中接收一个 ObjectManagerInterface 实例。这个 ObjectManager 是Extbase DI容器的核心，用于管理对象的创建和依赖解析。
3. GeneralUtility::makeInstance() 的局限性： GeneralUtility::makeInstance() 是TYPO3核心提供的一个通用工具，用于创建类的实例。然而，它本身并不具备Extbase DI容器的智能，无法自动解析和提供Extbase组件（如 Repository）所期望的复杂依赖项（如 ObjectManagerInterface）。当它尝试实例化 ArticleRepository 时，由于没有提供 ObjectManagerInterface 参数，导致 Repository 构造函数参数不足而报错。
4. 并发执行的影响： 尽管并发执行是触发这个问题的表面原因，但根本原因并非并发本身，而是不正确的依赖注入方式。在某些并发场景下，可能因为某种资源竞争或状态不一致，导致 GeneralUtility::makeInstance() 在特定时刻无法正确获取或传递 ObjectManagerInterface，从而暴露了底层依赖注入的缺陷。在单次或非并发执行中，可能由于环境或缓存状态的差异而未显现问题。

解决方案：使用Extbase的 @inject 注解

TYPO3 Extbase提供了一种优雅且标准化的依赖注入方式，即使用 @inject 注解。这种方式允许Extbase的 ObjectManager 自动处理依赖项的实例化和注入，无需手动在构造函数中进行 makeInstance 调用。

行者AI

行者AI绘图创作，唤醒新的灵感，创造更多可能

100

查看详情

修改后的FormFinisher代码应如下所示：

namespace [NAMESPACE]\[ExtName]\Domain\Finishers;

use TYPO3\CMS\Extbase\Annotation as ExtbaseAnnotation; // 引入Annotation命名空间别名
use TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager;
use [NAMESPACE]\[ExtName]\Domain\Repository\ArticleRepository;
use TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher;

class ImageGalleryFinisher extends AbstractFinisher
{
    /**
     * @var PersistenceManager
     * @ExtbaseAnnotation\Inject
     */
    protected $persistenceManager = null;

    /**
     * @var ArticleRepository
     * @ExtbaseAnnotation\Inject
     */
    protected $articleRepository = null;

    // 构造函数可以被删除，或者只保留父类构造函数的调用
    public function __construct()
    {
        parent::__construct();
        // 依赖项现在由Extbase的ObjectManager通过@inject注解自动注入
    }

    // ... 其他Finisher逻辑 ...
}

关键改动：

1. 引入 @ExtbaseAnnotation\Inject： 在需要注入的属性上方添加 @ExtbaseAnnotation\Inject 注解。注意，为了避免与PHP 8的Attributes混淆，TYPO3建议使用 \TYPO3\CMS\Extbase\Annotation\Inject 的完整命名空间，或者为其设置别名。
2. 删除手动实例化： 从构造函数中移除所有 GeneralUtility::makeInstance() 调用。Extbase的 ObjectManager 会在对象实例化后自动识别带有 @inject 注解的属性，并为其注入相应的实例。
3. 保留 parent::__construct()： 如果父类有自己的构造函数逻辑，保留 parent::__construct() 调用是必要的。

@inject 注解的工作原理

当Extbase的 ObjectManager 实例化 ImageGalleryFinisher 类时，它会：

1. 创建 ImageGalleryFinisher 的实例。
2. 扫描 ImageGalleryFinisher 类及其父类中带有 @ExtbaseAnnotation\Inject 注解的属性。
3. 根据属性的类型提示（@var 注解），从其内部容器中解析并获取相应的依赖实例（例如 PersistenceManager 和 ArticleRepository）。
4. 将这些依赖实例赋值给对应的属性。

这种机制确保了所有Extbase管理的依赖项都能以正确的方式、在正确的时机被注入，包括那些需要特定构造函数参数的Repository类。它避免了手动管理依赖的复杂性和潜在错误，尤其是在并发环境中。

注意事项与最佳实践

• 优先使用依赖注入： 在TYPO3 Extbase开发中，始终优先使用 @inject 注解进行依赖注入。这是Extbase框架推荐的模式，能够提高代码的可读性、可测试性和可维护性。
• 避免在Extbase上下文中使用 GeneralUtility::makeInstance()： 除非你明确知道自己在做什么，并且要实例化的对象不是Extbase管理的对象，否则应避免在Extbase组件（如Controller、Service、Repository、Finisher等）中使用 GeneralUtility::makeInstance() 来获取Extbase相关的依赖。
• 理解 ObjectManager： ObjectManager 是Extbase的核心组件之一，理解其工作原理对于深入开发Extbase应用至关重要。
• 类型提示的重要性： @var 注解不仅提供了代码提示，更重要的是，它为 @inject 注解提供了类型信息，以便 ObjectManager 知道要注入哪种类型的依赖。
• 并发稳定性： 采用正确的依赖注入方式，可以显著提高应用程序在并发请求下的稳定性，避免因资源竞争或不一致状态导致的运行时错误。

总结

TYPO3 Extbase中的“Too few arguments”错误，尤其是在并发场景下暴露，通常是由于在自定义组件中不正确地手动实例化Extbase依赖项所致。通过摒弃 GeneralUtility::makeInstance() 并在属性上使用 @ExtbaseAnnotation\Inject 注解，我们可以将依赖管理委托给Extbase的 ObjectManager，从而确保依赖项被正确、安全地注入。这不仅解决了并发执行可能带来的问题，也符合Extbase框架的最佳实践，提升了代码的健壮性和可维护性。

以上就是TYPO3 FormFinisher并发执行与Extbase依赖注入的最佳实践的详细内容，更多请关注php中文网其它相关文章！