Symfony 不使用容器访问配置参数

访问全局配置参数的推荐方式是什么？我知道你应该注入你所需要的，但是在大多数情况下，全局参数的要点是设置应用程序的默认值。我希望默认值是通用的，即使我允许逐个函数传递覆盖

问题 我有一个带有ViewVersionRepository的ViewVersion实体，其中我有与该实体交互的常用函数

其中一个函数要求我从config.yml中知道某个参数，例如cms.save.newVersionSeconds，以便我知道上次保存后的时间超过30分钟，并且我应该创建一个新的版本记录。但实体存储库不支持容器，因此我无法使用常规方法访问配置：

$myParam = $container->getParameter('my.custom.param');

从控制器注入

如果我从一个控制器调用这个函数，没问题，我可以在控制器中获得配置并将参数注入repo函数

$myParam = $container->getParameter('my.custom.param');
$viewVersionRepository->myFunction($myParam)

全球服务

或者，我可以将回购配置为服务：

gutensite_cms.view_version_repository:
    class: Gutensite\CmsBundle\Entity\View\ViewVersionRepository
    factory_service: 'doctrine.orm.cms_entity_manager'
    factory_method: 'getRepository'
    calls:
        - [setLimit, ['%cms.limit.list.admin%']]
        - [setNewVersionSeconds, ['%cms.save.newVersionSeconds%']]

然后通过services.yml中的calls参数使用setter注入设置参数。然后加载服务：

$viewVersionRepository = $this->container->get('gutensite_cms.view_version_repository');

复杂化

然而。。。我在一个事件侦听器中加载这个viewVersionRepository。在那里，我无法本地访问容器，因此无法实际加载全局服务。我可以访问实体，因此我通过以下方式加载回购：

$repo = $em->getRepository('GutensiteCmsBundle:View\ViewVersion);

但是当您以这种方式加载它时，它不会作为服务加载，因此setter注入不会发生

一个解决方案 因此，我可以将容器传递到全局onFlush事件侦听器服务中，这样我就可以将ViewVersionRepository作为一个服务加载，并在需要时让容器加载参数

gutensite_cms.listener.is_可版本化： 类：Gutensite\CmsBundle\EventListener\IsVersionableListener 只提供我们需要的服务 参数：[@gutensite\u cms.entity\u helper] 电话： -[setContainer，[@service_container]] 标签： -{name:doctrine.event_侦听器，事件：onFlush}

但我一次又一次地被告知，**只注入你需要的参数。避免注射整个容器。这个onFlush事件实际上是非常动态的，在具有onFlush方法的任何实体的存储库中加载相应的onFlush事件。因此，在一个实体存储库中，自定义函数可能需要访问一个参数，但在另一个实体存储库中，自定义函数可能需要访问另一个参数。所以我不能只传递一个参数

在我看来，传递整个容器会使应用程序的耦合性大大高于在全局默认配置中使用被诋毁的$GLOBALS或常量。因此，肯定有更好的方法来避免这两种邪恶。更不用说，永远不要将容器注入实体存储库

---

那么，在不注入整个容器的情况下，难道没有办法访问全局配置参数吗？在实体存储库中没有人需要全局配置参数吗？当然我可以将此功能移动到其他服务。。。但是为什么呢？这是该实体的基本功能之一，例如，它决定是否应该对其进行版本控制。

为什么不将参数注入onFlush，然后使用注入的参数作为参数调用存储库方法？这样，repository方法非常松散，您就不会拘泥于使用半硬编码参数。@Qoop此实体onFlush需要一个参数，但其他实体的其他onFlush方法可能需要不同的参数。因此，对我需要的参数进行硬编码似乎不是很灵活。我可以解决这个问题，但我想我想知道，对于平台设计，推荐的更大的解决方案是什么。拥有配置文件的目的是存储应用程序的默认配置。因此，在任何地方都必须注入这种配置，这看起来真的很奇怪。是的，可能会注入覆盖默认值的功能，但是如果没有指定，默认值应该很容易访问？这取决于您所说的灵活。如果您只注入一个参数，那么这个监听器可以被移动到不同的项目或框架，或者根本不需要框架，因为您只需要确保在构造中设置了这个参数。如果你的意思是你不需要事先考虑太多，那么注入容器会更容易，但是你会被绑定到一个只使用特定框架的侦听器，或者至少是一个使用相同类型interfaceCorrect的DI容器。在我的例子中，我正在构建一个CMS，代码是专门针对这个项目和这个项目的。它必须使你的代码必须能够以任何可想象的方式使用，即使你已经拥有了，也会让人感到虚弱。

---

没有这样做的计划。鉴于这种现实，有没有一种推荐的方法可以全局访问配置参数，而不必注入整个容器，因为容器本身是一种更糟糕的依赖性。谢谢我想你可以创建一个参数持有者对象，把你所有的参数都注入其中，然后把它注入你想在其中使用这些参数的东西中。这样，您就可以给它一个接口和类型提示，从而确保您至少得到了正确的对象。老实说，我真的看不出在每个服务上写出您想要的实际参数有什么问题，这样您就可以从YAML标记中看到每个服务中都有什么内容，而不必深入研究。公平地说，这真的取决于你。