清理查詢字符串

這是一個更開放的問題。你對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/

此所使用的全部接收路線抓住本質上是在過濾器上部分之後的替換查詢字符串。工作得很好，但在提交表單時發生故障。

我很想聽聽人們提出的其他解決方案嗎？有很多關於乾淨的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}/

這是否值得努力？

感謝，

來源

2009-08-07 madcapnmckay

「半打文本字段和兩個或複選框和選擇的三個列表相當簡單的搜索頁面。」 Google的搜索表單「非常簡單」。這個很複雜。在這種情況下，它可以產生一個複雜的URI。 – 2009-08-07 12:48:26

我個人的觀點是，如果用戶可能希望將網址加入書籤或將URL傳遞給其他人，那麼一個漂亮的，乾淨的「友好」網址就是要走的路。美學上他們更好。對於簡單的分頁和排序，重寫URL是個好主意。

但是，對於具有大數的臨時動態字段（如搜索）的頁面，我認爲謙虛的查詢字符串沒有問題。就像明智的頁面，其內容可能會改變顯着給予未來完全相同的URL。在這些情況下，使用查詢字符串的URL很好，甚至可能更好，因爲它們至少向observant用戶指示該頁面是動態的。但是，在這些情況下，使用表單POST變量可能會更好，無論如何，訪問者不會試圖用這些值「擺弄」。

來源

2009-08-07 12:15:20

不是不同領域的可在FormsCollection值反正在後？

來源

2009-08-07 12:10:59

是的，他們是這只是他們如何顯示在地址欄中。同樣爲了搜索，最好使用GET來搜索表單，以便它們可以被書籤。 – madcapnmckay 2009-08-07 12:31:26

好點。我想你可以將querystrings編譯成某種你可以更容易引用的結構？ - – 2009-08-07 12:39:42

除了其他人所說的之外，URL意味着語義層次結構。無論今天是否真實，祖先都是目錄，人們仍然認爲它是如此。這就是爲什麼你有控制器/動作/ ID。同樣，對於我來說，查詢字符串意味着選項或查詢。

個人而言，我認爲重寫網址是最好的，當你不知道它是否有一個解釋器 - 也許它只是一個生成的HTML文件？

所以，不管你選擇這麼做（這在客戶中是一種搜索形式的痛苦 - 我會說更麻煩，而不是價值），我會支持你爲層次結構做這件事。

E.g./搜索/國家/州/市

但是一旦你開始考慮價格和類型，或者不得不用一個數值類型（例如/prices=50.00/或更糟糕的數組），那就是你失去了我的地方。實際上，如果所有元素都被填充，那麼你真正完成的所有操作都是使用查詢字符串，用「/」替換「&」，然後將你的數組組合到一個字段中。

如果你將要反正編寫的代碼，你爲什麼不只是通過表單元素和循環：

取出空的，從清理查詢字符串「& price_low的= 「& price_high = &」各種各樣的東西。
將多個值到一個數組結構

但隨後提交作爲查詢字符串。

詹姆斯

來源

2009-08-07 13:13:41

清理查詢字符串

回答

相關問題