如何使用大量的查询参数来管理URL？

Question

您如何管理应用程序中的大URL(包含大量查询参数)？

例如，从ebay查看这个链接(不要点击这个链接只是一个大URL的例子)：

http://www.ebay.com/sch/Cameras-Photo-/625/i.html?LH_ItemCondition=1&LH_Price=15..500%40c&rt=nc&LH_Auction=1&LH_BIN=1&_nkw=nikon&_catref=1&_clu=2&_fcid=12&_fln=1&_localstpos=&_mPrRngCbx=1&_sc=1&_sop=15&_stpos=&_trksid=p3286.c0.m283&gbr=1

你可以看到很多类似于"_f"，"_sc“之类的奇怪和短的名字。

您不能在应用程序中使用这些参数，您需要转换为更“可读”的内容：

 $readableName = $_GET['_f'];

但是，以大量的var结尾，可能需要在一个函数中使用所有这些变量，因此，我们可以使用一个数组，而不是为每个查询param创建一个新的var：

$readableParams['readableName'] = $_GET['_f']; 

但是我们以一个具有任意结构的大数组结束，所以我认为最好的方法是为这些params设置一个VO (DTO)，类似于：

$filterVo = new FilterVo();
$filterVo->readableName = $_GET['_f'];

没关系，但是我们把密码放哪儿了？我的意思是，从“稀有的quer params”到“清除值对象”的转换在哪里是最好的地方？

因为我们还需要逆过程，所以我们可以用数据创建一个VO，然后从那个VO生成一个具有正确查询参数的URL。

在录影带里？助手URL类？视图模型基类？

--你是如何管理这些URL的？

Answer 1

有趣的是，您提到的输入名称是神秘的。我将在一般意义上(不仅仅是PHP细节)回答我在我的项目中看到的与这个主题相关的内容。总的办法是：

• 表单变量通常映射到对象。它是PHP中的VO或Java中的Beans。这将是最易读的转换形式(在我看来)，因为它为正在转换的
• 提供了上下文，在许多情况下，我看到了某种表单实用工具帮助类，它将处理往返转换。但是，这不是一个特定的硬编码转换，大多数转换是非常结构化和通用的。例如，它接受所有getters/setters方法，并将其用作表单名称。例如，我的对象中可能有getUsername()，然后表单实用程序就会将它转换为<input name="username"/>。
• 也可以通过映射覆盖覆盖默认映射。这可以是：
  • 配置文件的形式，例如将实例变量映射到表单变量的XML。在上面的示例中，这种映射可能是将用户名实例变量映射到一个名为u
  • 语言特性的更神秘的形式变量，例如在C#中进行注释或在C#中使用属性。语言特性允许在没有配置文件的情况下进行映射，但可以在对象源代码itself

中内联。

​

，

• ，我看到了一些项目，这些项目将有VO/Bean的基类，其中有利用上面提到的表单实用程序的fromForm(input)和toForm()。它为开发人员提供了方便，因此他们不必处理表单实用程序，而只需从其对象调用toForm()和fromForm(input)来处理该toForm()

考虑到上面的模式，对于神秘的表单字段，我通常看到：

创建VO对象来表示fields

• Create映射配置，以便将神秘字段映射到具有逻辑名称的实际实例变量(具有逻辑名称

• )，或者直接使用Form实用工具帮助类，或者如果在基类中使用表单实用程序，则使用方便的方法toForm()和fromForm(input)

。

Answer 2

这些参数大多是自动生成的。我在很多ASP.NET应用程序中都看到过这种行为。我讨厌.NET做这样的事情，但我不想再开始这个话题了。

大多数情况下，这些附加的参数是由插入模块生成的。这些工作是以自动化的方式完成的，这些工作并不直接反映在应用程序中(至少是应用程序的开发人员正在编写的部分)，或者帮助完成其他任务。这是一种跨请求维护状态的方法。

另一方面，您可以实现您描述的这样一种机制。在MVC环境中，这个任务将由Controller来处理。这只有在有很多GET参数被传递的情况下才有意义。你应该从一开始就避免这种做法。