清理查询字符串
这更像是一个悬而未决的问题。 您对 URL 中的查询字符串有何看法？ 在 ASP.NET MVC 中创建网站时，您会花费大量时间思考和制作干净的 URL，但在您第一次必须使用查询字符串（尤其是在搜索表单上）时，它们就会被破坏。
例如，我最近做了一个相当简单的搜索表单，其中有六个文本字段以及两三个复选框和选择列表。 这在提交时产生了下面的查询字符串。
countrylcid=2057&State=England&StateId=46&Where=&DateFrom=&DateTo=&Tags=&Keywords=&Types
=1&Types=0&Types=2&Types=3&Types=4&Types=5&Costs=0.0-9.99&Costs=10.00-29.99&Costs=30.00-59.99&Costs=60.00-10000.00
美丽我想你会同意的。 一半的字段中没有任何信息，并且列表输入确实非常冗长。
不久前，我为此实现了一个简单的分页解决方案，它生成了一个 url，例如
www.yourdomain.com/browse/filter-on/page-1/perpage-50/
This 使用了一个包罗万象的路由来获取过滤器部分之后本质上是替换查询字符串的内容。 工作得很好，但在提交表单时崩溃了。
我很想听听人们提出了哪些其他解决方案？ 有很多关于干净 url 的文章，但都是针对 ASP.NET 开发人员创建 MVC 已涵盖的基本静态 url 的。 我正在考虑深入研究模型绑定，以沿着这些思路产生适当的解决方案。 根据上述约定，大型查询字符串可以重写为：
filter-on/countrylcid-2057/state-England/stateId-46/types-{1,0,2,3,4,5}/costs-{0.0-9.99,10.00-29.99,30.00-59.99,60.00-10000.00}/
这值得付出努力吗？
谢谢，
This is more of an open question. What is your opinion on query strings in a URL? While creating sites in ASP.NET MVC you spend a lot of time thinking about and crafting clean URLs only for them to be shattered the first time you have to use query strings, especially on a search form.
For example I recently did a fairly simple search form with half a dozen text field and two or three lists of checkboxes and selects. This produced the query string below when submitted
countrylcid=2057&State=England&StateId=46&Where=&DateFrom=&DateTo=&Tags=&Keywords=&Types
=1&Types=0&Types=2&Types=3&Types=4&Types=5&Costs=0.0-9.99&Costs=10.00-29.99&Costs=30.00-59.99&Costs=60.00-10000.00
Beautiful I think you'll agree. Half the fields had no information in them and the list inputs are very verbose indeed.
A while ago I implemented a simple solution to this for paging which produced a url such as
www.yourdomain.com/browse/filter-on/page-1/perpage-50/
This used a catchall route to grab what is essentially a replacement query string after the filter-on portion. Works quite well but breaks down when doing form submissions.
Id be keen to hear what other solutions people have come up with? There are lots of articles on clean urls but are aimed at asp.net developers creating basic restful urls which MVC has covered. I am half considering diving into model binding to produce a proper solution along those lines. With the above convention the large query string could be rewritten as:
filter-on/countrylcid-2057/state-England/stateId-46/types-{1,0,2,3,4,5}/costs-{0.0-9.99,10.00-29.99,30.00-59.99,60.00-10000.00}/
Is this worth the effort?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了其他人所说的之外，URL 还意味着语义上的层次结构。 无论今天是否正确，祖先都是目录，人们仍然这样认为。 这就是为什么你有控制器/动作/id。 同样，对我来说，查询字符串意味着选项或查询。
就个人而言，我认为当您无法判断 URL 背后是否有解释器时，重写的 URL 是最好的——也许它只是一个生成的 HTML 文件？
因此，无论您选择如何执行此操作（在搜索表单中这对客户端来说都是一种痛苦 - 我想说麻烦大于其价值），我都支持您为层次结构执行此操作。
例如 /Search/Country/State/City
但一旦您开始了解价格和类型，或者必须在“目录”前面加上值的类型（例如 /prices=50.00/ 或更糟，使用数组），那么那就是你在哪里失去了我。
事实上，如果所有元素都已填写，那么您真正要做的就是获取查询字符串，替换“&” 与“/”，并将数组组合成一个字段。
如果您无论如何都要编写 JavaScript，为什么不循环遍历表单元素并：
，然后作为查询字符串提交。
詹姆士
In addition to what others have said, a URL implies a hierarchy that is semantic. Whether true today or not, the ancestry is directories and people still think of it as such. That's why you have controller/action/id. Likewise, to me a querystring implies options or queries.
Personally, I think a rewritten URL is best when you can't tell if there's an interpreter behind it -- maybe it's just a generated HTML file?
So however you choose to do it (and it's a pain on the client in a search form -- I'd say more trouble than it's worth), I'd support you doing it for hierarchies.
E.g. /Search/Country/State/City
but once you start getting into prices and types, or otherwise having to preface a "directory" with the type of value (e.g. /prices=50.00/ or worse, with an array), then that's where you've lost me.
In fact, if all elements are filled in, then all you've really done is taken the querystring, replaced "&" with "/", and combined your arrays into a single field.
If you're going to be writing the javascript anyways, why don't you just loop through the form elements and:
But then submit as a querystring.
James
无论如何，FormsCollection 中不同字段的值在发布时不可用吗？
Aren't the values of the different fields available in the FormsCollection anyway on post?
我个人的观点是，如果用户可能想要添加书签或将 URL 传递给其他人，那么一个漂亮、干净的“友好”URL 就是最佳选择。 从美学上来说，它们要好得多。 对于简单的分页和排序，重写 URL 是一个好主意。
但是，对于具有大量临时动态字段（例如搜索）的页面，我认为简单的查询字符串就可以了。 对于内容可能会在未来完全相同的 URL 发生显着变化的页面也是如此。 在这些情况下，带有查询字符串的 URL 很好，甚至可能更可取，因为它们至少向细心的用户表明该页面是动态的。 然而，在这些情况下，无论如何，使用表单 POST 变量可能会更好，这样访问者就不会试图“摆弄”这些值。
My personal view is that where users are likely to want to either bookmark or pass on URLs to other people then a nice, clean "friendly" URL is the way to go. Aesthetically they are much nicer. For simple pagination and ordering then a re-written URL is a good idea.
However, for pages that have a large number of temporary, dynamic fields (such as a search) then I think the humble query string is fine. Like wise for pages whose contents are likely to change significantly given the exact same URL in the future. In these cases, URLs with query strings are fine and, perhaps, even preferable as they at least indicate to the observant user that the page is dynamic. However, in these cases it may be better to use form POST variables, anyway, that way visitors are not tempted to "fiddle" with the values.