参数 - 此服务的最佳实践

Question

在阅读了很多关于Symfony2 DIC和语义配置之后，我问自己：“那么，现在我该如何处理达到我想要达到的目标？”

方案

想象一下，您想要创建一个非常像“管理仪表板调度程序”的服务 这意味着我有一些我想要做CRUD的实体。我不想做的是为我项目中的每个实体组合 route-＆gt; action-＆gt; logic ;那是因为，就这样，我必须为每个对象写一些类似的东西：

• / add / entity
• addEntityAction
• entityLogic

其中“entity”当然是object中实体的名称。

我正在构建一个服务（如调度程序），它将响应操作（add-delete-edit）但参数化：我会写入地址栏，如/add/entityA或{{1当我记得我的服务与实体名称时，那些路线将引导我采取相同的行动（当然） 此时，我的服务应该很聪明，知道对象中实体的EntityClass，FormTypeClass和模板文件是什么。

这就是我的精神混乱

我必须做一些预备配置，比如下面的php数组（这只是一个例子）

/add/entityB

或类似的东西。

但......

对于这种情况，考虑到只有我和我的团队才会使用此捆绑包（因此不是第三部分捆绑包），最佳做法是什么？

第一种解决方案

如果我定义了一些常量或静态成员，请使用array( 'EntityA'=>array( 'class'=>'BundleName/Entity/EntityA', 'form'=>'BundleName/Form/entityAType', 'template'=>'EntityATemplate'), 'EntityB'=>array( 'class'=>'BundleName/Entity/EntityB', 'form'=>'BundleName/Form/entityBType', 'template'=>'EntityBTemplate'), [...] ); 文件

第二种解决方案

将地图（如上一个数组）直接用于我的服务

第三种解决方案

为我的包使用语义配置，定义Extension类等等

如果我必须诚实，我不能说什么更好。显然第一个和第三个比第二个更好 第一个解决方案打破了symfony2哲学，但似乎是唯一的方法，因为第二个，只有当我必须触发创建一些直接处理我的DIC的服务（以cascad方式）或者具有配置层次结构时才有用，或者合并更多的一个配置文件，或（可能是第三方捆绑的最重要），以便在配置上进行某种验证。文件

你有什么看法？您是否看到其他方法可以做到这一点，或者您只是更喜欢第三种解决方案？我想知道你的意见。

编辑：显然我可以使用构建器注入或setter注入，但我将其视为“DIC”部分（因此，第三个解决方案）

Answer 1

如果您想以Symfony方式进行，我建议使用配置（如果我理解正确的话）：

acme_foo:
    entities:
        FooEntity:
            class_type: Acme\FooBundle\Entity\Foo
            form_type: Acme\FooBundle\Form\Type\FooType
            template: AcmeFooBundle:Entity:foo.html.twig
        BarEntity:
            class_type: Acme\FooBundle\Entity\Bar
            form_type: Acme\FooBundle\Form\Type\BarType
            template: AcmeFooBundle:Entity:bar.html.twig

使用AcmeFooExtension类，您可以设置包含配置的容器参数。然后，您可以将其注入您的服务（这是一个事件监听器）。调用/add/Foo时，您可以调度侦听器使用的acme_foo.entity_add事件。

您应该记住的是，您可以将所有放入config.php或parameters.php文件的内容放入应用配置（config.yml）。