Зачем вам когда-либо использовать объект хранилища asp.net ViewState поверх объекта хранилища сеанса?

Сессии заканчиваются, Viewstate - нет - вы можете вернуться через час, и ваше состояние просмотра будет по-прежнему доступно. Состояние просмотра также постоянно доступно при переходе назад / вперед по веб-сайту, при изменении сеанса.

Вся причина Viewstate или Session заключается в том, чтобы превратить Интернет из системы без отслеживания состояния в динамический, индивидуальный интерфейс. Когда пользователь запрашивает страницу, единственный способ возобновить работу с того места, где пользователь остановился, - это запомнить состояние либо на сервере, либо на клиенте пользователя.

Viewstate - это механизм запоминания состояния пользователя на клиенте. Сессия - это механизм запоминания состояния пользователя на сервере.

Viewstate - это временный механизм хранения. Состояние элементов управления, использующих viewstate, отображается на странице html как скрытый ввод. Во избежание подделки он подписан. Однако он не зашифрован, поэтому вы, вероятно, не захотите помещать в него НИЧЕГО конфиденциального. Viewstate полезен в ситуациях, когда вы хотите публиковать серию нескольких запросов (загрузка страницы). Примером этого является случай, когда форма не проверяется, потому что, возможно, пользователь ввел неверный адрес электронной почты или что-то в этом роде, и вы хотите восстановить форму в том виде, в котором она была до отправки пользователем. Недостатком этого является то, что viewstate - голодный зверь и может легко увеличить размер страницы на 30-50%.

Сессия же хранится на сервере. Клиент получает токен, который сообщает серверу, какой блок памяти принадлежит им. Это может быть намного безопаснее, чем viewstate, потому что данные не передаются пользователю снова и снова. Однако есть компромиссы. Вашему серверу может не хватить памяти. Или пользователь может потерять данные, если его сеанс будет прерван.

Как правило, не существует "правильного" ответа, на котором можно было бы использовать. Все дело в том, чего вы пытаетесь достичь.

Для большинства операций с элементами управления следует использовать Viewstate. Если вы имеете дело с конфиденциальной информацией, подумайте о сеансе. Если у вас есть данные для определенного набора страниц, используйте viewstate. Если это данные, которые вам понадобятся во время посещения пользователем вашего сайта, considier Session.

Например, когда ваше приложение может работать на компьютерной ферме, и вы не можете настроить сеанс для использования sql-сервера (или использование sql-сервера слишком сильно снижает производительность)

ViewState и Session имеют разные области видимости. ViewState предназначен для хранения более или менее переходных данных во время «обратной передачи», в то время как сеанс используется для сохранения критически важных данных о состоянии сеанса. Я рекомендую использовать ViewState для состояния, относящегося к определенному «сеансу страницы».

Если вам не нравится нормальное поведение ViewState, довольно просто написать свой собственный PageStatePersister и позволить этому объекту выполнять постоянство, например, используя сеанс или что-то вроде Memcached. Затем вы можете полностью переопределить механизм сохраняемости по умолчанию.

Затем хорошо то, что вы можете беспрепятственно продолжать использовать стандартные веб-элементы управления в .NET Framework, которые все будут использовать ViewState / ControlState для этого типа данных, не увеличивая ViewState. Механизм сохранения памяти сервера может быть очень эффективным.

Не совсем прямой ответ на ваш вопрос, но он может решить вашу проблему.

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

Создайте класс, унаследованный от страницы, и переопределите PageStatePersister. http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

 public class RussPage : Page
    {
         protected override PageStatePersister PageStatePersister
        {
            get
            {
                return new SessionPageStatePersister(Page);
            }
        }
    }

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

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

Не ответ на ваш вопрос, но одно из ваших предположений неверно.

Идентификаторы сеанса могут быть переданы в URL-адресе. Сессия не требует файлов cookie.

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

<sessionState cookieless="true" />

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