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

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, создающих базовые релакс-ссылки, которые 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

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

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

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

например. / Поиск / Страна / Штат / Город

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

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

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

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

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

Джеймс

Answer 3

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