Symfony2 : Why weren't query string parameters included in the routing component?

Question

我正在将一个遗留应用程序移植到 Symfony2 并且我正在苦苦挣扎，因为路由不包含查询字符串参数。一些简单的示例:假设您有一个书籍搜索页面，您可以在其中根据条件过滤结果:

http://www.bookstore.com/books?author=Stephen+King&maxPrice=20

在这种情况下，查询字符串参数的好处是您可以拥有任意数量的过滤器，将您想要的过滤器用于任何给定的请求，并且不会用您不使用的过滤器将 URL 塞满。

假设我们使用 Symfony2 路由组件重写了上述查询的路由。它可能看起来像这样:

http://www.mybookstore.com/book/any_title/stephen%20king/any_release_date/max_price_20/any_min_price/any_format/any_category

即使不考虑不干净的 URL 有多长，我仍然认为它不那么直观，因为该路由的每个“段”不是键值对，而只是一个值(例如 author=Stephen+King > /stephen%20king/ )。

您当然可以通过将 Request 对象传递到操作方法(例如 indexAction(Request $request) { )来访问 Controller 中的查询字符串参数，但是然后验证它们并将它们传递到应用程序的其他部分变得很麻烦(即我现在发现自己的地方)。如果您使用 Knp Menu Bundle 构建侧边栏，并且希望根据查询字符串参数将部分标记为 .current，该怎么办？没有任何功能，只有与 Symfony2 路由集成的功能。

以及如何验证您的查询字符串参数是否可以接受？我目前正在考虑像表单一样验证它们，然后将它们传递到数据库中以生成查询。也许这就是 Symfony2 团队设想的处理方式？如果是这样，我真的很想知道为什么。感觉就像我在与应用程序作斗争。

Answer 1

我最终在 Symfony Live San Francisco 2012 上向 Fabien 提出了这个问题。在同一个 session 上关于这个问题还有另一个演讲，我将在这里与你分享幻灯片:

http://www.slideshare.net/Wombert/phpjp-urls-rest#btnNext

基本上在幻灯片中，您可以看到作者同意我的观点，即查询字符串参数应该用于过滤。它们不应该用于确定内容源。因此，路由应指向产品(或其他)，然后应在 Controller 中使用查询字符串参数来应用过滤该内容源所需的任何逻辑(根据 Fabien)。

我最终在我的应用程序中创建了一个实体，我将所有查询字符串参数绑定(bind)到然后进行操作，这与处理表单的方式非常相似。事实上，当你考虑它时，它基本上是一样的。