При работе с одной страницей ViewState является лучшим выбором, чем QueryString, для поддержания состояния. Зачем? - PullRequest
2 голосов
/ 01 мая 2009

Я читаю статью: Девять параметров для управления постоянным состоянием пользователя в приложении ASP.NET Стивен А. Смит (Разве он не ведет шоу на ESPN?)

В этой статье Стивен делает следующее утверждение: «При работе с одной страницей ASP.NET ViewState - лучший выбор для поддержания состояния, чем QueryString» *

К сожалению, он не объясняет, почему это так. Почему это так?

Ответы [ 5 ]

12 голосов
/ 01 мая 2009

Я полагаю, потому что QueryString является частью URI страницы - и, таким образом, может быть подделан пользователем. Не говоря уже о том, что в QueryString есть ограниченное пространство - ограничено максимальным размером URL (2048 байт в IE, другие браузеры более удобны).

Помимо взлома, сохранение случайных битов состояния в QueryString приведет к очень уродливым URL-адресам - и, следовательно, к URL-адресам, которые недружествены для поисковых систем.

4 голосов
/ 01 мая 2009

Я заметил, что вы включили ASP.NET MVC в свои теги для этого вопроса. Вы должны знать, что ASP.NET MVC не имеет ViewState. На всех.

4 голосов
/ 01 мая 2009

Это не так.

ViewState хранится внутри самой страницы, в скрытом поле формы. Это полезно в сценариях, в которых состояние фактически является переходным - WebForms полагается на него по умолчанию для состояния управления - но единственный способ для него сохранить при загрузке страницы - принудительно выполнять обратную передачу каждый раз, когда запрос сделал на сервер.

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

Обратите внимание, что логически, и ViewState, и состояние, хранящиеся в строках запроса, зависят от страницы; хотя они могут быть перенаправлены на другую страницу как часть запроса GET (строка запроса) или POST (ViewState), браузер сам не будет связывать их с запросами на отдельные страницы и не будет обновлять эти состояния при возврате на предыдущую страницу. , Небольшое количество дополнительной защиты, предоставляемой ViewState (как Эрик отмечает ), - возможно, поэтому г-н Смит рекомендует его для хранения пользовательского -конкретного состояния на одноместном стр. Тем не менее, хаки, заставляющие их работать на нескольких страницах в стороне, это вложение на каждой странице, как правило, делает файлы cookie (или состояние сеанса на стороне сервера, индексированные файлом cookie на стороне клиента) более подходящими для состояния удержания, характерного для данного пользователя или сеанса, но не относится ни к одной отдельной странице.

Лично я никогда не находил ViewState особенно полезным - он хрупок и накладывает серьезные ограничения на то, как может выполняться навигация. Однако, если вы придерживаетесь чистой модели обратной передачи / перенаправления WebForms, ее можно заставить работать эффективно (так как фреймворк будет обрабатывать большинство уродливых деталей за вас). Имейте в виду, что попытка сделать слишком много на одной странице может привести к очень большому количеству ViewState и соответственно к медленному времени загрузки / перезагрузки для ваших пользователей.

1 голос
/ 01 мая 2009

Эрик прав, но я бы также добавил, что в ASP.NET ViewState сериализуется в скрытый элемент формы для вас. Идея состоит в том, что вы можете хранить что угодно в ViewState (даже сложные объекты), и они будут сериализованы автоматически , в то время как хранение таких объектов в QueryString обычно означает их деконструкцию вручную и запись какого-то парсера восстановить их.

0 голосов
/ 01 мая 2009

Все зависит.

Элементы в вашей QueryString могут быть глубоко связаны. Вы можете этого не хотеть или вам придется кодировать вокруг этого.

Длина строки запроса ограничена. Не то, чтобы кто-то помещал 10K в их viewstate, но я поставил более чем 2k limit * на QueryString в ViewState при необходимости. Не то, что вы можете сделать вообще с QyeryString.

В большинстве случаев вам следует использовать комбинацию обоих. С MVC вы теряете ViewState, но в некоторых случаях, скорее всего, будете разрабатывать собственное подобное решение.

EDIT: * Различные браузеры поддерживают разную максимальную длину, но все же проблема. http://www.aspfaq.com/show.asp?id=2222

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...