2008-10-24 3 views
21

Предположим, у вас есть страница aspx, которая не полагается на сеанс, но полагается на viewstate для стойкости между postbacks.Срок действия визы истекает?

Если пользователь обращается к этой странице и уезжает на длительный обед, будет ли виза, которая будет действительна, когда он вернется?

ответ

9

No ViewState не поддерживается как часть процесса PostBack. Однако вы можете использовать override свойства SavePageStateToPersistenceMedium() и LoadPageStateFromPersistenceMedium() класса страницы для реализации этого поведения, если это необходимо. Для получения дополнительной информации см. Understanding the ASP.NET ViewState.

Обратите внимание, что Page ViewState хранится в сессии, так что если истекает ваша сессия, то ViewState будут потеряны. Я бы не сказал, что это устаревшая версия ViewState, но да, она будет уничтожена после таймаута сеанса.

+1

Как «Нет» помечено как ответ? Viewstate не истекает, это переменные формы. Записанные учетные данные пользователя могут истечь в этом сценарии, но это все. – 2010-10-28 22:36:26

+1

Я даже не уверен, что ответ wprl «Нет». это зависит от того, отсутствует ли запятая после слова «Нет».В любом случае я изо всех сил пытаюсь понять, что этот ответ пытается сказать. – Andy 2015-06-08 14:46:27

14

Внешний вид Viewstate не истекает. Поскольку он отправлен обратно в форме, он может быть восстановлен в любое время.

According to MSDN: ". ..это можно указать, что состояние истекает, если страница не была отправлена ​​обратно в течение срока действия сеанса". Таким образом, в раунде примерно так, он может истечь, если ваш сеанс работает, но viewstate не истекает напрямую. Поскольку вы все равно не используете состояние сеанса, вам не нужно беспокоиться о неявном истечении срока действия.

Обратите внимание, что я бы не сказал, что это истекло. Это была MS, которую я цитировал в их собственной статье под названием Controlling ViewState

2

Viewstate не истекает, если они все еще находятся на странице, она все равно будет работать и функционировать.

5

Viewstate не действует.

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

Это имеет некоторые очень интересные последствия, и объясняется очень тщательно here.

1

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

1

По умолчанию Viewstate входит в состав содержимого html как скрытый ввод. Это означает, что он не истечет, но что все в viewstate должно быть загружено из браузера пользователя. Так как это, как правило, самая медленная часть соединения на общедоступном сайте, добавив много вещей в viewstate, вы можете быстро сделать свой сайт очень медленным.

1

Короткий ответ: нет.

Более длинный ответ: это зависит от реализации хранилища ViewState. Вы можете предоставить пользовательскую реализацию ViewState, которая может истечь через заданное количество времени. Например, вы можете хранить ViewState в базе данных или на диске и отправлять только некоторую ссылку на сохраненное значение в скрытом поле. Затем вы можете использовать пакетную обработку для удаления устаревших данных ViewState или выполнения срока действия по запросу.

2

ViewState будет сохраняться от POST до POST. Он фактически хранится внутри скрытого поля в вашей форме, чтобы он постоянно возвращался к вашему серверу.

До тех пор, пока вы не полагаетесь на сеанс, у вас не должно возникнуть проблем с восстановлением состояния страницы. Легко проверить код состояния вашей страницы, если вы хотите: просто установите, что ваш сеанс истекает через 60 секунд в вашем web.config, затем загрузите свою страницу, подождите немного больше минуты (переходите к переполнению стека и отвечайте на некоторые вопросы) а затем нажмите кнопку на своей странице.

5

Кроме того, как полученный, по умолчанию ASP.NET шифрует ViewState с помощью автогенерированного ключа. Это можно переопределить с помощью элемента MachineKey в файле web.congif. Несмотря на то, что ViewState не истекает, он может стать недействительным, если для дешифрования ViewState используется другой автогенерированный ключ, например, после сброса IIS, перераспределения приложения или попадания на другой сервер в веб-ферме. Если вы планируете хранить просмотр в течение длительного времени, следите за тем, как он зашифрован/расшифрован.

http://msdn.microsoft.com/en-us/library/ms998288.aspx

5

Да, ViewState истекает в определенных условиях. Например, когда вы используете iframe: s, или когда вы поддерживаете «живое» соединение с сервером с регулярными обратными передачами. Затем вы можете изучить этот параметр: <sessionPageState historySize="9"/>, который на самом деле жестко кодирует, сколько «результатов обратной передачи» хранится в сеансе (если используется SessionPageStatePerster). Каждый postback хранит его ViewState в конце очереди в сеансе ["__ VIEWSTATEQUEUE"] и удаляет ViewStates, которые являются «слишком старыми». И как вы думаете, SessionPageStatePerster решает, какие ViewStates являются слишком старыми .. путем настройки некоторой произвольной historySize-константы в web.config .. Omg! Это тоже меня навсегда, чтобы найти эту проблему ... Моя ненависть к asp.net программирование undescribable сейчас .. гррр ...

2

К сожалению, чтобы вновь пережить эту старую нить, но новая информация в настоящее время:

Да, ViewStates истекает. Я прихожу с 19 часов, исследуя проблему ViewStates, теряющую свои значения между ретрансляцией длинных интервалов времени. Мне потребовалось некоторое время, читая MSDN-документы и ответы Stackoverflow, говоря, что это было практически невозможно, если не была применена пользовательская реализация хранилища ViewState, которая, как я знаю, это неправда.

Моя проблема происходила в среде SharePoint 2013. Сервис, известный как Распределенный кеш (a.k.a. AppFabric) выполняет кэширование ViewState и связан с ним . Время жизни. Вы можете найти более подробную информацию здесь: http://blogs.msdn.com/b/besidethepoint/archive/2013/03/27/appfabric-caching-and-sharepoint-1.aspx

Интересный бит информации можно найти в этой фразе: «Для того, чтобы улучшить производительность страницы, начиная с SharePoint 2013 SharePoint кэширует ViewState данных на стороне сервера, а не передача его обратно и для клиентов ».

Надеюсь, эта информация поможет кому-то так отчаянно, как я был 19 часов назад.

Смежные вопросы