在typo3 extbase开发中，自定义formfinisher在处理并发提交时，若采用不当的依赖注入方式，可能导致“too few arguments”错误。本文将深入探讨这一问题，解释其根本原因，并提供基于extbase `@inject` 注解的标准化解决方案，确保在多用户同时操作下应用的稳定性和健壮性。
TYPO3 Extbase自定义FormFinisher中的依赖注入挑战
在TYPO3 CMS的Extbase框架中，开发自定义功能时，我们经常需要引入其他服务或仓库（Repository）。当涉及到自定义FormFinisher并处理并发请求时，一个常见的陷阱是尝试在构造函数中手动实例化依赖项，这可能导致在特定条件下出现“Too few arguments to function TYPO3CMSExtbasePersistenceRepository::__construct()”的错误。
问题描述
假设我们有一个自定义的FormFinisher，其构造函数中通过 GeneralUtility::makeInstance() 方法来获取 PersistenceManager 和一个自定义的 ArticleRepository 实例，代码示例如下：
namespace [NAMESPACE][ExtName]DomainFinishers;use TYPO3CMSCoreUtilityGeneralUtility;use TYPO3CMSExtbasePersistenceGenericPersistenceManager;use [NAMESPACE][ExtName]DomainRepositoryArticleRepository;use TYPO3CMSFormDomainFinishersAbstractFinisher;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 TYPO3CMSExtbasePersistenceRepository::__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 参数。
// TYPO3CMSExtbasePersistenceRepository.phppublic function __construct(ObjectManagerInterface $objectManager){ $this->objectManager = $objectManager; $this->objectType = ClassNamingUtility::translateRepositoryNameToModelName($this->getRepositoryClassName());}
问题根源分析
这个问题的核心在于对Extbase依赖注入机制的误解和不当使用。
Extbase的依赖注入容器： Extbase框架拥有自己的依赖注入（DI）容器，它负责管理Extbase组件（如Controller、Service、Repository等）的生命周期和依赖关系。当Extbase实例化一个对象时，它会检查该对象的所有依赖项，并自动将它们注入到构造函数或通过setter方法注入。Repository 构造函数的期望： 所有的Extbase Repository 类都期望在构造函数中接收一个 ObjectManagerInterface 实例。这个 ObjectManager 是Extbase DI容器的核心，用于管理对象的创建和依赖解析。GeneralUtility::makeInstance() 的局限性： GeneralUtility::makeInstance() 是TYPO3核心提供的一个通用工具，用于创建类的实例。然而，它本身并不具备Extbase DI容器的智能，无法自动解析和提供Extbase组件（如 Repository）所期望的复杂依赖项（如 ObjectManagerInterface）。当它尝试实例化 ArticleRepository 时，由于没有提供 ObjectManagerInterface 参数，导致 Repository 构造函数参数不足而报错。并发执行的影响： 尽管并发执行是触发这个问题的表面原因，但根本原因并非并发本身，而是不正确的依赖注入方式。在某些并发场景下，可能因为某种资源竞争或状态不一致，导致 GeneralUtility::makeInstance() 在特定时刻无法正确获取或传递 ObjectManagerInterface，从而暴露了底层依赖注入的缺陷。在单次或非并发执行中，可能由于环境或缓存状态的差异而未显现问题。
解决方案：使用Extbase的 @inject 注解
TYPO3 Extbase提供了一种优雅且标准化的依赖注入方式，即使用 @inject 注解。这种方式允许Extbase的 ObjectManager 自动处理依赖项的实例化和注入，无需手动在构造函数中进行 makeInstance 调用。
修改后的FormFinisher代码应如下所示：
namespace [NAMESPACE][ExtName]DomainFinishers;use TYPO3CMSExtbaseAnnotation as ExtbaseAnnotation; // 引入Annotation命名空间别名use TYPO3CMSExtbasePersistenceGenericPersistenceManager;use [NAMESPACE][ExtName]DomainRepositoryArticleRepository;use TYPO3CMSFormDomainFinishersAbstractFinisher;class ImageGalleryFinisher extends AbstractFinisher{ /** * @var PersistenceManager * @ExtbaseAnnotationInject */ protected $persistenceManager = null; /** * @var ArticleRepository * @ExtbaseAnnotationInject */ protected $articleRepository = null; // 构造函数可以被删除，或者只保留父类构造函数的调用 public function __construct() { parent::__construct(); // 依赖项现在由Extbase的ObjectManager通过@inject注解自动注入 } // ... 其他Finisher逻辑 ...}
关键改动：
引入 @ExtbaseAnnotationInject： 在需要注入的属性上方添加 @ExtbaseAnnotationInject 注解。注意，为了避免与PHP 8的Attributes混淆，TYPO3建议使用 TYPO3CMSExtbaseAnnotationInject 的完整命名空间，或者为其设置别名。删除手动实例化： 从构造函数中移除所有 GeneralUtility::makeInstance() 调用。Extbase的 ObjectManager 会在对象实例化后自动识别带有 @inject 注解的属性，并为其注入相应的实例。保留 parent::__construct()： 如果父类有自己的构造函数逻辑，保留 parent::__construct() 调用是必要的。
@inject 注解的工作原理
当Extbase的 ObjectManager 实例化 ImageGalleryFinisher 类时，它会：
创建 ImageGalleryFinisher 的实例。扫描 ImageGalleryFinisher 类及其父类中带有 @ExtbaseAnnotationInject 注解的属性。根据属性的类型提示（@var 注解），从其内部容器中解析并获取相应的依赖实例（例如 PersistenceManager 和 ArticleRepository）。将这些依赖实例赋值给对应的属性。
这种机制确保了所有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() 并在属性上使用 @ExtbaseAnnotationInject 注解，我们可以将依赖管理委托给Extbase的 ObjectManager，从而确保依赖项被正确、安全地注入。这不仅解决了并发执行可能带来的问题，也符合Extbase框架的最佳实践，提升了代码的健壮性和可维护性。
以上就是TYPO3 FormFinisher并发执行与Extbase依赖注入的最佳实践的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1325009.html
微信扫一扫 
支付宝扫一扫 
