Очистка строк запроса

Question

Это скорее открытый вопрос. Как вы оцениваете строки запроса в 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, создающих базовые успокоительные URL-адреса, которые охватил MVC. Я в два раза рассматриваю возможность погружения в привязку к модели для создания правильного решения по этим направлениям. В соответствии с вышеприведенной конвенцией большую строку запроса можно было бы переписать как:

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}/ 

Это стоит усилий?

Спасибо,

Answer 1

Мое личное мнение заключается в том, что, когда пользователи, вероятно, захотят либо пометить закладку, либо передать URL-адреса другим людям, тогда хороший, чистый «дружественный» URL-адрес - это путь. Эстетически они намного приятнее. Для простой разбивки на страницы и упорядочения тогда переписанный URL-адрес - хорошая идея.

Однако для страниц с большим числом временных динамических полей (таких как поиск), то я думаю, что смиренная строка запроса в порядке. Как мудрый для страниц, содержимое которых, вероятно, изменит значительно, учитывая тот же URL в будущем. В этих случаях URL-адреса с строками запросов являются точными и, возможно, даже предпочтительными, поскольку они, по крайней мере, указывают наблюдательному пользователю, что страница является динамической. Однако в этих случаях лучше использовать переменные формы POST, так или иначе, посетители не испытывают соблазна «играть» со значениями.

Answer 2

Не являются ли значения различных полей, доступных в любом случае FormsCollection на посту?

Answer 3

В дополнение к тому, что говорили другие, URL-адрес подразумевает семантическую иерархию. Верно ли сегодня или нет, родословная - это каталоги, и люди все еще думают об этом как таковом. Вот почему у вас есть контроллер/action/id. Аналогично, для меня querystring подразумевает варианты или запросы.

Лично я считаю, что переписанный URL-адрес лучше всего, когда вы не можете определить, есть ли у него интерпретатор - может быть, это всего лишь сгенерированный HTML-файл?

Так что вы решили сделать это (и это боль на клиенте в форме поиска - я бы сказал, больше проблем, чем это стоит), я бы поддержал вас, делая это для иерархий.

E.g./ Search/Country/State/City

, но как только вы начинаете входить в цены и типы или иначе должны вводить «каталог» с типом значения (например, /prices = 50.00/ или хуже, с массивом) , тогда именно там вы меня потеряли.

Фактически, если все элементы заполнены, то все, что вы действительно сделали, берется за строку запроса, заменяя «&» на «/» и объединяет ваши массивы в одно поле.

Если вы собираетесь писать на JavaScript в любом случае, почему вы не просто петлю через форму элементов и:

1. Удалите пустые, очистка строки запроса от "& price_low = & price_high = & "виды вещей.
2. Объединение нескольких значений в виде массива

Но затем представить в виде строки запроса.

Джеймс