这更像是一个悬而未决的问题。您对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
美丽我想你会同意的。一半的字段中没有信息，列表输入确实非常冗长。
前段时间我为分页实现了一个简单的解决方案，产生了一个网址，例如
www.yourdomain.com/browse/filter-on/page-1/perpage-50/
这使用了一个catchall路由来获取在过滤器部分之后本质上是替换查询字符串。工作得很好，但在提交表单时会出现故障。
我很想知道人们提出的其他解决方案吗？有很多关于干净网址的文章，但针对的是asp.net开发人员创建MVC所涵盖的基本的restful 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}/
值得努力吗？
谢谢，
答案 0 :(得分：2)
我个人认为，如果用户可能想要将网址加入书签或传递给其他人，那么就可以使用一个漂亮，干净的“友好”网址。在美学上它们更好。对于简单的分页和排序，然后重写URL是个好主意。
但是，对于具有大数的临时动态字段（例如搜索）的页面，我认为简陋的查询字符串很好。对于内容可能会在未来给出完全相同的URL 显着的页面来说是明智的。在这些情况下，具有查询字符串的URL很好，甚至可能更优选，因为它们至少向观察用户指示该页面是动态的。但是，在这些情况下，使用表单POST变量可能会更好，无论如何，访问者不会试图“摆弄”这些值。
答案 1 :(得分：2)
除了其他人所说的，URL意味着语义层次结构。无论今天是否真实，祖先都是目录，人们仍然会这样想。这就是你有控制器/动作/ id的原因。同样，对我来说，查询字符串意味着选项或查询。
就个人而言，我认为当你不知道背后是否有解释器时，重写的URL是最好的 - 也许它只是一个生成的HTML文件？
所以你选择这样做（而且在搜索表单中客户端很痛苦 - 我会说它比它的价值更麻烦），我支持你为层次结构做这件事。
E.g。 /搜索/国家/国家/城市
但是一旦你开始涉及价格和类型，或者不得不在一个带有值类型的“目录”前面（例如/prices=50.00/或更糟，带有数组），那么那就是你失去了我的地方
事实上，如果填写了所有元素，那么你所做的一切都是查询字符串，取而代之的是“＆amp;”使用“/”，并将数组合并为一个字段。
如果您打算编写javascript，为什么不循环使用表单元素：
但随后提交为查询字符串。
詹姆斯
答案 2 :(得分：0)
在帖子中，FormCollection中的不同字段的值是否仍然可用？