Состояние сеанса v ViewState

В нашем приложении у нас есть «BasePage», который объявляет ряд свойств, которые будут использоваться более или менее каждой страницей в приложении.

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

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

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

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


asp.net session viewstate
person Solyad    schedule 14.12.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Никогда не доверяйте данным, отправленным вашим пользователем.

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

Какие у вас варианты хранения данных?

  • Скрытое поле; можно легко подделать на стороне клиента
  • Cookie; древний метод хранения пользовательских данных, но очень ограниченный по размеру.
  • ViewState; ваши данные отправляются клиенту и возвращаются, используя пропускную способность, и могут быть подделаны.
  • Сессия, InProc; у вас никогда не будет проблем, пока пул приложений не будет переработан
  • Сессия, Государственный сервер; вы храните данные сеанса в другом серверном процессе.
  • Сессия, база данных; может работать почти со всеми (если не всеми) сценариями балансировки нагрузки, так как вам не нужны сеансы накопителя и не нужно беспокоиться об утилизации пулов приложений. Все ваши данные принадлежат нам вашему SQL Server.

Читая ваш сценарий, вам, вероятно, придется иметь дело с внепроцессным хранилищем сеансов.

person Rubens Farias    schedule 14.12.2009
comment
Я думаю, что в нашем случае я буду придерживаться viewstate, поскольку объекты очень легкие. Я измерил состояние просмотра до и после настройки, и оно крошечное. Мы действительно смотрели на хранилище сеансов sql вне процедуры, но наши специалисты по инфраструктуре сказали, что это не стоит снижения производительности из-за увеличения нагрузки ввода-вывода (имейте в виду, что мы можем взглянуть на это еще раз, если наша среда изменится, а мы должны). Тем не менее, хорошее резюме вариантов, спасибо. По крайней мере, из того, что я прочитал все эти сообщения, кроме увеличенного размера страницы, я не делаю ничего принципиально неправильного как такового. - person Solyad; 14.12.2009

arrow_upward
2
arrow_downward

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

Я бы сохранил значения в ViewState или cookie.

person Chris Fulstow    schedule 14.12.2009

arrow_upward
1
arrow_downward

Если это не конфиденциальные данные, я бы также предпочел хранить их в HTML, а не в сеансе.

person Darin Dimitrov    schedule 14.12.2009