ASP.NET ViewState postback с обновлением страницы и закладками

Question

Функция ASP.NET ViewState иногда может быть обоюдоострым мечом. Я полагаюсь на это на большинстве своих проектов и значительно ускоряет разработку.

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

Современные браузеры будут показывать глупые диалоговые окна, когда пользователь попытается обновить страницу, которая является результатом операции POST (например, asp postback), которая нежелательна вообще.

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

Примером того, что я могу сделать, является наличие рядом с ними страницы с записями и флажками, у пользователя есть возможность проверить все записи, которые они хотят удалить, а затем нажмите кнопку «Удалить». После того, как пользователь нажимает на удаление, анализы анализируются на сервере, а на новой странице отображаются все записи, которые были выбраны с помощью кнопки подтверждения подтверждения. Теперь, если пользователь нажимает кнопку «Обновить», он получает эту глупую коробку, чтобы подтвердить, хотят ли они отправлять сообщения или нет.

Я понимаю, что ViewState является результатом использования модели Post Back, что означает, что большинство страниц asp.net являются результатом операции POST, но мне интересно, существуют ли какие-либо способы ее использования.

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

P.S. Я понимаю, что я могу использовать Response.Redirect() и/или запрос строки, но я хочу использовать простоту ViewState

Answer 1

Я дам мое мнение здесь один за один раз.

Тот факт, что диалог предупреждает вас о повторном посту, - это хорошая вещь ИМО. Что, если это была страница проверки и повторная отправка, как-то в конечном итоге снова зарядили кредитную карту пользователя. Я согласен, что формулировка может быть лучше в диалоге, но мы там, где мы находимся.

Если вы думаете о поведении закладок, это означает, что я хочу снова и снова просматривать эту страницу, но, скорее всего, моя сессия закончится задолго до того, как это произойдет. Таким образом, вы можете сохранить viewstate в GUID, но тогда вам придется держать это viewstate в базе данных потенциально навсегда. Что делать, если страница меняется? Это viewstate будет теперь недействительным.

Несомненно, в вашем случае вам нужен параметр строки запроса, который будет загружать данные пользователя из базы данных и заполнять страницу во время page_load как обычно? www.my-site.com/Customer.aspx?Id=90401 или что-то в этом роде.

Мое предложение состоит в том, чтобы не бороться с инструментами. Надеюсь это поможет.

Answer 2

Моего 2 цента: Вместо того, чтобы использовать простоту ViewState песка использовать простоту сессии - которая на самом деле является тем же простотой и вам не придется беспокоиться беспокоиться о обновлении страницы и прочем. Кроме того, сеанс является более гибким, так как вы можете использовать его для хранения не только встроенных типов, но и не влияющих на производительность (вы также можете сделать это с помощью ViewState, но это повлияет на производительность).

Answer 3

Это может быть не изящное решение, но я думаю, что если вы измените метод формы на GET, он решает проблему с вашей закладкой и обновит ее.

Это то же самое как с использованием строк запроса, но с абстракцией VIEWSTATE оставлено нетронутым.

Answer 4

@Asaf - Я не вниз голосовать свой ответ, но вот несколько причин:

1) не может хранить сложные типы в строке запроса строка 2) Запрос ограничен до 2Kb в IE, который не так много 3) Неправильное использование метода GET - GET буквально для «получения» данных (например, строки поиска Google), а POST - для «отправки» данных на сервер, чтобы управлять данными на сервер (например, контактные формы). 4) Все, что полагается на Page.IsPostBack, перестанет работать.