Зачем тебе это? asp.net объект хранения ViewState над объектом хранения сеанса?

кроме того, что хранилище сеансов является глобальным для нескольких страниц, почему вы хотите использовать viewstate для хранения значений?

кажется смешным отправлять любую информацию, кроме нескольких небольших строк запроса, таких как значения, назад и вперед от клиента к серверу. Я имею в виду, что пустая трата полосы пропускания(!), просто для целей хранения. Сеанс, будучи глобальным на нескольких страницах, кажется полностью превосходной альтернативой viewstate.

особенно с asp.net ajax элементы управления и варианты, viewstate может быстро стать раздутым отслеживания различных состояний и переменных всех этих различных элементов управления и html-элементов.

но тогда почему вообще существует хранилище viewstate для переменных и объектов страницы?

может быть, мне не хватает еще одного отличного использования для хранения viewstate страницы, кто-нибудь знает что-то там?

Спасибо за чтение!

EDIT: все у меня был отличный ответ, извини, если я не выбрал твой.

16
asp.net session-storage storage viewstate

8 ответов

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

22

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

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

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

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

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

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

11

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

5

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

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

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

5

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

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

4

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

вы можете хранить 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);
            }
        }
    }
3

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

идентификаторы сеанса могут быть переданы в URL. Сеанс не требует cookies.

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

<sessionState cookieless="true" />
2

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

1