How to manage URLs with a lot of query params?

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 conversi开发者_如何转开发on 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?

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)

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.