如何管理具有大量查询参数的 URL?

发布于 2024-12-03 10:55:38 字数 1387 浏览 0 评论 0原文

您如何在应用程序中管理大型 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=ni kon&_catref=1&_clu=2&_fcid=12&_fln=1&_localstpos=&_mPrRngCbx=1&_sc=1&_sop=15&_stpos=&_trksid=p3286.c0.m283&gbr=1< /a>

您可以看到很多参数,其中许多参数具有奇怪且短的名称,例如“_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):

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

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

煞人兵器 2024-12-10 10:55:38

有趣的是,您提出输入名称是神秘的。我将从一般意义上(不仅仅是 PHP 细节)回答我在项目中看到的、我认为与该主题相关的内容。一般方法:

  • 表单变量通常映射到一个对象。它是 PHP 中的 VO 或 Java 中的 Bean。这将是最易读的转换形式(在我看来),因为它为正在转换的 HTML 表单提供了上下文
  • 。在许多情况下,我见过某种表单实用程序帮助器类,它将处理来回转换。然而,这不是特定的硬编码转换,大多数转换都是非常结构化和通用的。例如,它采用所有 getter/setter 方法并将其用作表单名称。例如,我的对象中可能有 getUsername() ,然后表单实用程序会将其转换为
  • 或者,您还可以通过映射覆盖来覆盖默认映射。这可以是以下形式:
    • 配置文件,例如将实例变量映射到表单变量的 XML 文件。在上面的示例中,此类映射可能是将 username 实例变量映射到名为 u 的更神秘的表单变量
    • 语言特性,例如 Java 中的注释或 C# 中的属性。语言功能允许在没有配置文件的情况下进行映射,而是内联在对象源代码本身中
  • 我见过一些项目,这些项目将具有 VO/Bean 的基类,该 VO/Bean 具有 fromForm(input)toForm() 利用上面提到的表单实用程序。它为开发人员提供了便利,因此他们不必处理表单实用程序,只需从其对象中调用 toForm()fromForm(input) 即可

立即 处理转换给定上面的模式,对于神秘的表单字段,我通常会看到:

  • 创建 VO 对象来表示字段
  • 创建映射配置以将神秘字段映射到具有逻辑名称的实际实例变量
  • 直接使用 Form Utilities 帮助程序类,或者如果 Form Utilities用于基地类,使用便捷方法 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:

  • The form variables are normally mapped to an object. It's a VO in PHP or Beans in Java. This would be the most readable forms of transformation (in my opinion) as it gives context to the HTML forms that are being converted
  • In many cases, I've seen some kind of Form Utilities Helper class that will handle the transformation to and from. However, this is not a specific hardcoded transformation, most of the transformation is very structured and generic. For example, it takes all the getters/setters method and use that as a form name. For example, I might have getUsername() in my object, then the Form Utilities will translate it into <input name="username"/> for example.
  • Optionally, you could also override the default mapping via mapping override. This could be in the form of :
    • Configuration file, for example an XML File that maps the instance variable to the the form variable. In the example above, such mapping could be to map username instance variable to a more cryptic form variable named u
    • Language feature such as annotation in Java or Attribute in C#. The language feature would allow the mapping to be made without configuration file but inline in the object source code itself
  • I've seen projects that would have base class for the VO/Bean that has fromForm(input) and toForm() 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 call toForm() and fromForm(input) from their object to handle the transformation

Now given the pattern above, for cryptic form fields, I normally see:

  • Create VO object to represent the fields
  • Create mapping configuration to map the cryptic field to the actual instance variable with logical name
  • Either use Form Utilities helper class directly, or if the Form Utilities used in the base class, use the convenience methods toForm() and fromForm(input)
娇女薄笑 2024-12-10 10:55:38

大多数参数都是自动生成的。我在很多 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文