如何管理具有大量查询参数的 URL?
您如何在应用程序中管理大型 URL(带有大量查询参数)?
例如,查看 ebay 上的此链接(不要单击该链接,该链接只是一个大 URL 的示例):
您可以看到很多参数,其中许多参数具有奇怪且短的名称,例如“_f”、“_sc”等。
您不能在应用程序中使用这些参数,您需要转换为更“可读”的内容:
$readableName = $_GET['_f'];
但是然后你以很多变量结束,并且可能你需要在一个函数中使用所有它们,因此,我们可以使用数组来代替每个查询参数的新变量:
$readableParams['readableName'] = $_GET['_f'];
但是然后我们以一个具有任意结构的大数组结束,所以我认为最好的主意是这些参数的 VO (DTO),类似于:
$filterVo = new FilterVo();
$filterVo->readableName = $_GET['_f'];
没关系,但是我们将该代码放在哪里?我的意思是,从“罕见的查询参数”转换为“明确的值对象”的最佳位置在哪里?
因为我们还需要逆过程,所以我们可以创建一个带有数据的 VO,然后从该 VO 生成一个带有正确查询参数的 URL。
VO 里面? 辅助 URL 类? 查看模型基类?
您如何管理这些带有大量参数的网址?
How are you managing big URLs (with a lot of query parameters) in your app?
For example, look this link from ebay (don't click the link is just an example of a big URL):
You can see a lot of params, many of them with strange and short names like "_f", "_sc" etc.
You can't use those params in your app, you need to convert to something more "readable":
$readableName = $_GET['_f'];
but then you end with a lot of vars, and probably you need all of them in a function, so, instead of a new var for every query param we can use an array:
$readableParams['readableName'] = $_GET['_f'];
But then we end with a big array with an arbitrary structure, so I think the best idea is to have a VO (DTO) for those params, something like:
$filterVo = new FilterVo();
$filterVo->readableName = $_GET['_f'];
That's OK, but where we put that code? I mean, where is the best place to make the conversion from "rare quer params" to "clear value objects"?
Because we also need the inverse process, so we can create a VO with data, and then generate a URL with the correct query params from that VO.
Inside the VO?
Helper URL class?
View Model base class?
How are you managing these URLs with a lot of params?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
有趣的是,您提出输入名称是神秘的。我将从一般意义上(不仅仅是 PHP 细节)回答我在项目中看到的、我认为与该主题相关的内容。一般方法:
getUsername()
,然后表单实用程序会将其转换为。
fromForm(input)
和toForm()
利用上面提到的表单实用程序。它为开发人员提供了便利,因此他们不必处理表单实用程序,只需从其对象中调用toForm()
和fromForm(input)
即可立即 处理转换给定上面的模式,对于神秘的表单字段,我通常会看到:
toForm()
和fromForm(input)
It's interesting that you brought up the input names are cryptic. I am going to answer in general sense (not only PHP specifics) on what I've seen in my projects that I think pertinent to this topic. The general approach:
getUsername()
in my object, then the Form Utilities will translate it into<input name="username"/>
for example.fromForm(input)
andtoForm()
that utilize the Form Utilities mentioned above. It provides convenience to the developers so they don't have to deal with Form Utilities but simply calltoForm()
andfromForm(input)
from their object to handle the transformationNow given the pattern above, for cryptic form fields, I normally see:
toForm()
andfromForm(input)
大多数参数都是自动生成的。我在很多 ASP.NET 应用程序中都看到过这种行为。我讨厌 .NET 做这样的事情,但我不想再次开始这个话题。
大多数时候,这些附加参数是由嵌入式模块生成的。它们以自动化的方式工作,执行一些未直接反映在应用程序中的事情(至少是应用程序开发人员正在编写的部分),或协助其他任务。这是一种跨请求维护状态的方法。
另一方面,您可以实现您描述的这种机制。在 MVC 环境中,此任务将由控制器处理。仅当您传递大量 GET 参数时,这才有意义。你应该从一开始就尽量避免这种做法。
Most of those parameters are auto-generated. I have seen this kind of behaviour in a lot of ASP.NET apps. And I hate .NET for doing such stuff, but I don't want to start that topic again.
Most of the time these additional parameters are generated by drop-in modules. These work in an automated way doing some stuff that isn't directly reflected in the app (the part the developer of the application is writing at least), or assist in other tasks. It's a way to maintain state across requests.
On the other hand you could implement such a mechanism you describe. In an MVC environment this task would be handled by the Controller. This only makes sense if you have A LOT of GET parameters getting passed. You should try to avoid this kind of practice from a beginning.