在typo3自定义表单完成器中，当多个请求同时执行时，手动通过`generalutility::makeinstance`实例化extbase仓库可能导致`too few arguments`错误，因为extbase仓库的构造函数需要`objectmanagerinterface`参数。本文将深入分析此问题，并提供基于extbase `@inject` 注解的官方推荐解决方案，确保并发场景下依赖注入的正确性和稳定性。

理解TYPO3 Extbase中的依赖注入与并发问题

在TYPO3的Extbase框架中，开发人员经常需要创建自定义的表单完成器（Form Finisher）来处理表单提交后的业务逻辑。然而，当这些完成器在短时间内被多个用户同时触发时，如果依赖项（如Extbase仓库或持久化管理器）的实例化方式不当，就可能引发意料之外的错误，例如经典的“Too few arguments to function”异常。

问题的核心在于Extbase组件（尤其是Repository）的构造函数期望接收特定的依赖项，例如ObjectManagerInterface。当开发者在自定义完成器的构造函数中手动使用GeneralUtility::makeInstance()来实例化这些依赖时，特别是在并发环境下，可能会遇到以下情况：

1. Extbase Repository的构造函数要求： TYPO3/CMS/Extbase/Persistence/Repository的构造函数明确要求一个ObjectManagerInterface实例作为参数。

   public function __construct(ObjectManagerInterface $objectManager)
   {
       $this->objectManager = $objectManager;
       // ...
   }

   登录后复制
2. GeneralUtility::makeInstance()的行为： GeneralUtility::makeInstance()是一个通用的实例化工具。在某些情况下，当它尝试实例化一个Extbase Repository时，可能无法正确地推断并提供ObjectManagerInterface参数，尤其是在首次实例化或并发请求导致容器状态不一致时。这就会导致Too few arguments错误，因为Repository的构造函数没有收到预期的参数。
3. 并发执行的挑战： 在多个表单提交几乎同时发生时，系统可能会尝试并发地实例化完成器及其依赖。这种并发性可能会暴露GeneralUtility::makeInstance()在处理Extbase特定依赖注入方面的局限性，导致一个请求成功，而另一个请求失败。

考虑以下一个自定义表单完成器的错误示例：

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

use TYPO3/CMS/Core/Utility/GeneralUtility;
use TYPO3/CMS/Extbase/Persistence/Generic/PersistenceManager;
use [NAMESPACE]/[ExtName]/Domain/Repository/ArticleRepository;

class ImageGalleryFinisher extends /TYPO3/CMS/Form/Domain/Finishers/AbstractFinisher
{
    /**
     * @var PersistenceManager $persistenceManager
     */
    protected $persistenceManager = null;

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

    public function __construct()
    {
        parent::__construct();
        // 错误的方式：手动实例化Extbase依赖
        $this->persistenceManager = GeneralUtility::makeInstance(PersistenceManager::class);
        $this->articleRepository = GeneralUtility::makeInstance(ArticleRepository::class); // 此处易出错
    }

    // ... 其他方法
}

当上述代码中的$this-youjiankuohaophpcnarticleRepository = GeneralUtility::makeInstance(ArticleRepository::class);被执行时，如果GeneralUtility::makeInstance未能为ArticleRepository的构造函数提供ObjectManagerInterface，就会抛出Too few arguments异常。

解决方案：利用Extbase的依赖注入机制

TYPO3 Extbase框架提供了一套健壮的依赖注入（Dependency Injection, DI）机制，旨在简化对象实例化和依赖管理。对于Extbase管理的类（如控制器、服务、表单完成器、仓库等），推荐使用Extbase的DI功能来自动注入依赖，而不是手动调用GeneralUtility::makeInstance()。

Extbase的DI主要通过两种方式实现：属性注入（Property Injection）和构造函数注入（Constructor Injection）。对于本例中遇到的问题，属性注入是简洁且有效的解决方案。

表单大师AI

一款基于自然语言处理技术的智能在线表单创建工具，可以帮助用户快速、高效地生成各类专业表单。

74

查看详情

属性注入（Property Injection）

通过在类属性上添加@/TYPO3/CMS/Extbase/Annotation/Inject注解，Extbase的Object Manager会在对象实例化后自动识别并注入对应的依赖实例。这种方式无需手动编写构造函数来处理这些特定依赖，从而避免了GeneralUtility::makeInstance()可能带来的问题。

修正后的自定义表单完成器代码：

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

use TYPO3/CMS/Extbase/Persistence/Generic/PersistenceManager;
use [NAMESPACE]/[ExtName]/Domain/Repository/ArticleRepository;
use TYPO3/CMS/Extbase/Annotation as Extbase; // 导入注解命名空间，简化写法

class ImageGalleryFinisher extends /TYPO3/CMS/Form/Domain/Finishers/AbstractFinisher
{
    /**
     * @var PersistenceManager
     * @Extbase/Inject // 使用Extbase的Inject注解
     */
    protected $persistenceManager = null;

    /**
     * @var ArticleRepository
     * @Extbase/Inject // 使用Extbase的Inject注解
     */
    protected $articleRepository = null;

    // 删除自定义的__construct方法，或仅保留父类构造函数的调用
    public function __construct()
    {
        parent::__construct();
        // 不再需要手动实例化Extbase依赖
    }

    // ... 其他方法
}

代码解释：

1. use TYPO3/CMS/Extbase/Annotation as Extbase;: 导入注解命名空间，使得 @Extbase/Inject 可以替代冗长的 */TYPO3/CMS/Extbase/Annotation/Inject。
2. @Extbase/Inject 注解: 当Extbase的Object Manager实例化ImageGalleryFinisher时，它会扫描所有带有@Extbase/Inject注解的属性。对于每个这样的属性，Object Manager会尝试根据属性的类型声明（例如PersistenceManager或ArticleRepository）自动查找并注入一个合适的实例。
3. 移除手动实例化: 由于Extbase的DI机制会自动处理这些依赖，我们不再需要在完成器的构造函数中手动调用GeneralUtility::makeInstance()。这不仅解决了Too few arguments的问题，也使代码更简洁、更符合框架规范。

注意事项与最佳实践

• 优先使用框架DI: 对于Extbase管理的组件（如控制器、服务、仓库、命令控制器、表单完成器等），始终优先使用Extbase提供的依赖注入机制（@inject注解或构造函数注入）来获取依赖。
• GeneralUtility::makeInstance()的适用场景: GeneralUtility::makeInstance()并非完全无用。它适用于实例化那些不属于Extbase DI容器管理、或者不需要复杂依赖解析的普通PHP类。例如，如果你需要一个简单的工具类实例，且该工具类没有复杂的构造函数依赖，makeInstance()仍然是一个可行的选择。
• 并发稳定性: 使用Extbase的DI机制可以显著提高应用程序在并发环境下的稳定性。框架的Object Manager负责确保依赖项的正确实例化和生命周期管理，从而避免了手动实例化可能引入的竞态条件或状态不一致问题。
• 构造函数注入: 对于自定义的服务或复杂的依赖关系，也可以考虑使用构造函数注入（即在构造函数中声明类型提示的参数，并让TYPO3的DI容器自动解析）。这在某些场景下提供了更明确的依赖声明，并且是现代PHP开发中推荐的DI实践。

总结

当在TYPO3自定义表单完成器中遇到并发执行导致的“Too few arguments”异常时，其根本原因通常是手动通过GeneralUtility::makeInstance()实例化Extbase依赖（如Repository）与Extbase框架的依赖注入期望不符。通过采纳Extbase官方推荐的属性注入（使用@/TYPO3/CMS/Extbase/Annotation/Inject注解），可以优雅地解决这一问题。这种方法不仅保证了依赖项的正确注入，提升了代码的健壮性和可维护性，也确保了应用程序在多用户并发场景下的稳定运行。始终遵循框架的DI最佳实践，是构建高质量TYPO3扩展的关键。

以上就是TYPO3自定义表单完成器并发执行异常的解析与最佳实践的详细内容，更多请关注php中文网其它相关文章！

https://www.php.cn/faq/1627016.html