Question

我需要为每条路线实现各种元数据属性，我的一个想法是将属性直接应用到每条路线上，以供外部元数据监听器使用。

例如，侦听器将使用在以下路由中定义的服务（@example_title_resolver）来解析某种形式的页面标题。

example_route:
    path:     /blah/blah
    defaults:
        _controller: MyBundle:MyController:index
        meta:
            title:
                resolver: '@example_title_resolver'
                value: 'Example | %%value_to_be_resolved%% | %default_title_suffix%'

不幸的是，虽然params得到了解决，但我发现服务却没有。现在解决这种方法的唯一方法是将服务容器直接注入监听器，并查询服务，这是不受欢迎的。

还有更好的选择吗？鉴于我真的很难找到解决路线内的服务问题，这整个方法是否应该避免？

Answer 1

以下是我最终解决的问题：

<强>路线

example_route:
    path:     /blah/blah
    defaults:
        _controller: MyBundle:MyController:index
        meta:
            title:
                resolver: '@example_title_resolver'
                value: 'Example | %%value_to_be_resolved%% | %default_title_suffix%'

听众1 - 服务解析器。 在RouterListener之后立即调用，优先级为33或更高，此时路由参数已应用于请求（@see https://github.com/symfony/http-kernel/blob/master/EventListener/RouterListener.php#L97）。

附加到kernel.request事件的侦听器检查了请求参数，并解决了注入侦听器的服务容器的所有服务（前缀为@的字符串值）。

监听器2 - 元数据监听器。 此时，路由/请求上的所有内容都已解析为服务。这解决了问题，并允许更多不相关的听众从与请求中直接可用服务交谈的能力中受益。

在此示例中，元数据侦听器将在请求中查找特定的params（已解析的服务）。例如，这些对象将用于解析元数据值。然后需要一种通用机制来使该数据可供视图使用。

解析程序类 负责将给定的模板字符串转换为最终值。由上面的元数据监听器调用。

<强>优点

分开关注点，使控制器更具可重用性。
灵活，允许开发/丢弃轻量级解析器类。
在元数据的特定情况下，当不可避免地某些路由需要添加新类型的元数据时，提供了一种很好的未来验证方式。这只是一个新的解析器，也是路线的一小部分。

<强>缺点

陌生眼睛出乎意料的魔力。
如果处理不当，服务解析请求中的值可能是一个安全问题。

我现在要开始这样做，因为优势很吸引人。我会在解决方案不再适合时办理登机手续。

Symfony：解决路线上的服务问题

1 个答案: