Как можно управлять состояниями в asp net приложение
Может ли кто-нибудь дать мне подходящие примеры ситуаций, когда я должен использовать эти методы?
ОТВЕТЫ
Ответ 1
Вариант управления государством
Используйте, когда вам нужно хранить небольшие объемы информации для страницы, которая будет отправляться обратно в себя. Использование свойства ViewState обеспечивает функциональность базовой безопасности.
Используйте, когда вам нужно хранить небольшие объемы информации о состоянии для управления между общими поездками на сервер.
Используйте, когда вам нужно хранить небольшие объемы информации для страницы, которая будет отправляться обратно на себя или на другую страницу, и когда безопасность не является проблемой.
Вы можете использовать скрытое поле только на страницах, которые отправляются на сервер.
Используйте, когда вам нужно хранить небольшие сведения о клиенте, а безопасность не является проблемой.
Используйте, когда вы переносите небольшие объемы информации с одной страницы на другую, и безопасность не является проблемой.
Строки запроса можно использовать только в том случае, если вы запрашиваете одну и ту же страницу или другую страницу по ссылке.
Параметры управления сервером
Использовать при хранении редко изменяемой глобальной информации, которая используется многими пользователями, и безопасность не является проблемой. Не храните большое количество информации в состоянии приложения.
Используйте, когда вы храните краткосрочную информацию, относящуюся к отдельному сеансу, и проблема безопасности. Не храните большое количество информации в состоянии сеанса. Имейте в виду, что объект состояния сеанса будет создан и сохранен для жизни каждого сеанса в вашем приложении. В приложениях с множеством пользователей это может занимать значительные ресурсы сервера и влиять на масштабируемость.
Используйте, когда вы храните информацию о пользователе, которая должна сохраняться после истечения срока действия пользовательского сеанса, и ее необходимо снова получить при последующих посещениях вашего приложения.
Поддержка базы данных
Используйте, когда вы храните большое количество информации, управляете транзакциями или информация должна выдерживать перезагрузку приложений и сеансов. Углубление данных вызывает озабоченность, и проблема с безопасностью.
Ответ 2
На это может повлиять множество факторов, поэтому я не буду комментировать их все. Но вот несколько указателей:
Query String - Используйте это, чтобы сохранить состояние, которое вам нужно, чтобы позволить пользователю закладок на странице или процесс и вернуться к намного позже. Даже тогда вы можете захотеть сохранить его до какого-то хэша, который вы можете использовать в качестве ключа в поиске базы данных, чтобы избежать действительно огромного URL-адреса (хотя хеши имеют свои проблемы). Кроме того, многие пользователи любят возиться с вашей строкой запроса напрямую, так что опасно слишком много вкладывать здесь. Это легко случайно подвергнуть данные пользователям, которые не должны его видеть таким образом.
Cookies - Не используйте файлы cookie для хранения учетных данных пользователя. Это просто незашифрованные текстовые файлы. Используйте файлы cookie для хранения ключа в сеансе (даже здесь вы можете и должны теперь использовать сеансы без файлов cookie) и простые параметры персонализации, которые будут специфичны для этого пользователя и браузера. Например, размер моего монитора на рабочем месте отличается от домашнего, и поэтому установка параметров размера экрана/макета в куки файл хороша, потому что настройки привязаны к каждому компьютеру, но это не будет нарушать мою безопасность, если кто-то еще прочтет, что информация.
Теперь я хочу выделить эту концепцию из раздела "Строка запроса":
вы можете захотеть сохранить его до какого-либо хэша, который вы можете использовать в качестве ключа в поиске базы данных
- Вытягивание данных с клиента происходит медленно для общедоступных интернет-сайтов. Даже широкополосные соединения обычно наносят ущерб пропускной способности, доступной для загрузки. 512Kpbs (по-прежнему типичная широкополосная скорость загрузки во многих областях) ничто по сравнению с Gigabit Ethernet (или более быстрым) соединением, которое, вероятно, находится между вашей базой данных и вашим веб-сервером. Насколько вы можете думать о запросе базы данных как медленном (и это так), все же, вероятно, гораздо лучший способ пойти, чем ждать, пока одни и те же данные поступят от клиента.
- Сохранение данных на сервере дешевле, потому что вы не платите за пропускную способность, требуемую для его нажатия или от клиента, а пропускная способность часто стоит столько же или больше, чем ваше серверное оборудование.
- Это более безопасно, потому что, если все сделано правильно, даже если клиентский компьютер или соединение скомпрометированы, все хакеры имеют доступ к изначально хеш-ключам, которые, вероятно, истекают к тому моменту, когда он сможет его расшифровать. Конечно, если все сделано неправильно, он может сразу использовать этот ключ, поэтому вам все равно нужно быть осторожным.
Поэтому для большинства вещей я рекомендую начинать с хранения ключа базы данных в сеансе, а затем с помощью кода легко извлекать то, что вам нужно, из базы данных на основе этого ключа. Когда вы сталкиваетесь с узкими местами, профилями, чтобы узнать, где они находятся, и начните кэшировать эти страницы или элементы управления или сохранить результат данных/запроса непосредственно в сеансе.
Ответ 3
Не уверен, что вы имеете в виду объект Кэш по статусу приложения.
Объект Cache - отличный способ управлять состоянием широкого приложения, например. для записи источника и подсчета доступа к вашему сайту (например, для предотвращения атак DDOS).
Ответ 4
(3) Строка запроса (4) Состояние сессии (5) Состояние приложения (6) Печенье
1. VIEWSTATE
- Отказ от ответственности: используйте как можно меньше. Хороший момент - всегда иметь доступ к каждому государству по URL-адресу, если это возможно.
- F.e. Пейджинг должен использовать URL-адрес (так /url/?p=2 вместо сохранения страницы в Viewstate)
- F.e. Сохраните выбранный элемент в флажке, чтобы вы могли определить, изменилось ли оно.
2. Проводка с перекрестными страницами
не делать. См. Отказ от ответственности для viewstate. Используйте URL-адрес для этого или сохраните данные в сеансе/файле cookie/profile, если необходимо сохранить грузы свойств.
3. Строка запроса
Используйте много. Каждое видимое состояние, которое может достигнуть страница, должно быть доступно по URL-адресу. Люди с программами чтения будут благодарны вам за это. И с помощью строки запроса нет необходимости использовать только javascript-решения.
4. Состояние сеанса
Используйте это для короткоживущих объектов, которые имеют смысл только на этот раз, когда посетитель посещает ваш сайт. Например:
Не используйте сеансы, но профили для таких вещей, как:
Потому что эти вещи также имеют смысл в следующий раз, когда пользователь посещает ваш сайт.
5. Состояние приложения
6. Cookies
Идентификатор сеанса, идентификатор профиля для аутентифицированных пользователей; пользовательские настройки для анонимных пользователей (все перечисленные во втором списке ниже 4.).
Состояние приложения похоже на состояние сеанса. Оно поддерживает объекты тех же типов, хранит информацию на сервере и использует синтаксис, основанный на словаре. Наиболее распространенным примером применения состояния приложения является глобальный счетчик, отслеживающий информацию о том, сколько" раз отдельная операция выполнялась всеми клиентами данного веб-приложения.
Например, можно было бы создать обработчик событий в файле global.asax, который отслеживал бы число созданных сеансов или количество поступивших в приложение запросов. Или же можно было бы применить подобную логику в обработчике событий Page.Load для отслеживания количества запросов данной страницы различными клиентами. Ниже показан код для реализации последнего варианта:
Опять-таки, элементы состояния приложения хранятся в виде объектов, поэтому при извлечении из коллекции они должны приводиться к соответствующему типу. Время жизни элементов состояния приложения никогда не истекает. Они существуют до тех пор, пока приложение или сервер не будет перезапущен, или до тех пор, пока не произойдет автоматическое обновление домена приложения (согласно установленным настройкам либо в результате обновления одной из страниц или компонентов в приложении).
Состояние приложения применяется редко, потому что, как правило, является неэффективным. В предыдущем примере счетчик вряд ли бы всегда отображал точное значение, особенно при насыщенном трафике. Например, в случае, если бы одну и ту же страницу одновременно запросили два пользователя, последовательность событий выглядела следующим образом:
Пользователь А извлекает текущее значение счетчика (432).
Пользователь Б извлекает текущее значение счетчика (432).
Пользователь А устанавливает значение счетчика в 433.
Пользователь Б устанавливает значение счетчика в 433.
Другими словами, один из этих запросов не учитывается, потому что два клиента получают доступ к счетчику одновременно. Во избежание этой проблемы, следует использовать методы Lock() и UnLock(), которые явно позволяют получать доступ к коллекции состояния Application только одному клиенту за раз:
В прошлом коллекция состояния Application использовалась для хранения констант уровня приложения, таких как строка подключения к базе данных. Теперь же, константы такого типа теперь могут сохраняться в файле web.config; такой подход более удобен, потому что позволяет легко изменять эти константы, не выискивая их в коде веб-страницы и не компилируя приложение заново.
Состояние приложения поставляется главным образом для обратной совместимости с классической версией ASP. В новых приложениях для глобальных данных лучше применять другие подходы, например, использовать базу данных вместе с объектом Cache.
В ASP . Net предоставляет два типа управления состоянием веб – приложения: на клиенте и на сервере. Каждый из этих типов обладает отличительными особенностями, с которыми мы и познакомимся в ходе лекции.
Управление состоянием веб – приложения на стороне клиента
Преимущества хранения информации на стороне клиента:
- Лучшая масштабируемость. При управлении состоянием на сервере каждый подключившийся к веб-серверу клиент занимает часть ресурсов сервера. Если сайт одновременно посещают сотни и тысячи пользователей, для хранения их состояния им потребуется много памяти, которая может стать узким местом. Устранить его можно, переложив управление данными состояния на пользователей;
- Поддержка множества веб-серверов. При управлении состоянием на клиенте обработку поступающих запросов можно распределить среди множества веб-серверов, не модифицируя код приложения, так как клиент предоставляет веб-серверу всю необходимую информацию. При управлении состоянием на сервере клиент в середине сеанса может обратится к другому серверу, но у того может не оказаться доступа к состоянию клиента. При управлении состоянием на сервере с использованием группы серверов необходима интеллектуальная балансировка нагрузки (пересылающая запросы одного клиента одному и тому же серверу) либо централизованное управление состоянием (когда состояние хранится в центральной базе данных, доступной всем веб-серверам).
Методы хранения сведений на стороне клиента, необходимых для управления состоянием:
- ViewState или состояние отображения – отслеживает значения элементов управления;
- ControlState или состояние элемента управления – применяется при создании пользовательских элементов управления, как правило, используется для корректной работы пользовательского ЭУ, даже в случае отключения ViewState ;
- Скрытые поля – данные сохраняются в HTML – форме и являются невидимыми для браузера;
- Cookie – файлы – эти файлы хранят введенные в браузер значения, которые браузер отсылает на сервер при последующих запросах данной страницы;
- Строки запроса – сохраняют значения в составе URL.
ViewState
View State —называется способ хранения данных о состоянии страницы в скрытом поле формы на самой странице. Данные из скрытого поля используются, чтобы для конкретного клиента установить состояние серверных объектов , формирующих страницу.
Чтобы отключить состояние отображения веб-элемента управления, присвойте его свойству EnableViewState значение False . Это ускорит обработку данных на сервере и уменьшит размер страницы.
Также можно откоючить ViewState и на уровне страницы:
Важно следующее: по – умолчанию, состояние отображение включено у каждого элемента управления, что не всегда хорошо. Прежде всего, при использовании ViewState страница становится "тяжелее", как для обработки, так и для передачи клиенту, из-за дополнительного объема. Далее, дополнительная нагрузка связана с формированием и разбором данных скрытого поля ViewState . И, наконец, для обработки View State все-таки требуется память на сервере.
Поэтому перед началом разработки следует определиться с тем на каких страницах использование ViewState необходимо, для остальных же, лучше состояние отображения отключить.
В случае, если в ViewState планируется хранить конфиденциальные данные (чего, строго говоря, следует, при возможности, избегать), можно включить шифрование
Чтобы включить шифрование состояния отображения в приложении, в файле Web.config присвойте атрибуту <pages viewStateEncryptionMode> значение Always :
Запись данных ViewState
В объект ViewState можно добавлять пользовательские значения. В следующем примере после проверки наличия объекта ViewState , записывается дата последнего посещения пользователя:
Чтение данных ViewState
В следующем примере после проверки наличия объекта ViewState , отображается дата последнего посещения страницы пользователем:
ControlState
Обычно ControlState используется для того, чтобы элемент управления работал корректно в случае EnableViewState = false . Если на работу вашего ЭУ никак не влияет ViewState – то нет смысла применять ControlState .
Скрытые поля
Преимущества использования скрытых полей :
- Не требуются ресурсы сервера. Скрытое поле сохраняется на странице и считывается с нее.
- Широкая поддержка. Практически все обозреватели и клиентские устройства поддерживают формы со скрытыми полями.
- Простая реализация. Скрытые поля представляют собой стандартные элементы управления HTML , которым не требуются сложные программные алгоритмы.
Недостатки использования скрытых полей :
- Потенциальная угроза безопасности. Скрытое поле может быть подделано. Сведения в скрытом поле можно увидеть, если источник выходных данных страницы просматривается напрямую, что создает потенциальную угрозу безопасности.
- сложные типы данных . Скрытые поля содержат поле с одним строковым значением, в которое помещается информация. Для сохранения нескольких значений необходимо реализовать разделенные строки и код, анализирующий эти строки.
- Вопросы производительности. Поскольку скрытые поля сохраняются на самой странице, при сохранении больших значений процесс отображения и отправки страницы может замедлиться.
- Ограничения размера хранилища. Если объем данных в скрытом поле становится слишком большим, то некоторые прокси-серверы и брандмауэры будут запрещать доступ к странице, содержащей эти данные.
Пример сохранения данных:
Свойство HiddenField. Value имеет тип String , поэтому перед его установкой требуется преобразовать данные в тип String .
- Какому количеству пользователей должна быть доступна информация?
- Как долго информация должна храниться?
- Какие объемы информации необходимо сохранять?
- Какие требования к секретности информации?
Отвечая на эти вопросы, можно определить какой из следующих подходов использовать.
Все методы можно разделить на две категории: клиентские, т.е. информация будет храниться на стороне клиента и серверные, т.е. информация будет храниться на стороне сервера. Достоинством клиентских методов является отсутствие необходимости использовать серверные ресурсы для хранения информации, а недостатком - требования секретности, т.к. любая отосланная на клиентскую машину информация может быть искажена потенциальным злоумышленником. Для серверных способов ситуация диаметрально противоположная. Рассмотрим каждый из них более детально.
Клиентские методы
ViewState
Данный контейнер позволяет пользователю сохранять значения следующим образом:
Этот способ применим на веб-страницах и пользовательских контролах (наследниках классов Page и UserControl соответственно). В коллекцию ViewState можно занести любой сериализуемый объект, либо имеющий TypeConverter для преобразования его в строку. Контейнер оптимизирован для хранения примитивных типов, а также String, ArrayList, HashTable. В случае сохранения других типов рекомендуется перегрузить методы LoadViewState и SaveViewState, в которых реализовать свою более эффективную методику.
Кроме того, эти методы необходимо перегружать в custom контролах (наследниках класса WebControl). Предположим, что custom контрол сохраняет свое состояние во ViewState под ключом X. Этот контрол размещается на некоторой странице, которая также сохраняет свое состояние во ViewState под таким же ключом X. В результате одно из значений будет потеряно, что, вероятно, приведет к неправильной работе. Поэтому в custom контролах настоятельно рекомендуются пользоваться следующим способом:
На использование ViewState также влияют два атрибута директивы @Page, которая определяет любую aspx страницу. Первый из них EnableViewStateMac, установка которого в true сообщает системе о необходимости шифрования hidden поля _VIEWSTATE. Второй - EnableViewState, позволяющий отключить использование коллекции. Т.е. при EnableViewState=false выполнение вышеуказанного кода даст strColor=null. Однако, посмотрев html код страницы, для которой отключен ViewState, мы все равно увидим hidden поле __VIEWSTATE. Это связано с тем, что ViewState также хранит некоторую системную информацию, например id активной формы страницы.
Поскольку все данные будут храниться в одном hidden поле, то не рекомендуется использовать данный контейнер для больших объектов, поскольку это может существенно увеличить размер страницы и скорость ее загрузки. В определенной степени размер ViewState можно уменьшить за счет упаковки поля.
Cookie
Кроме вышеуказанных способов, можно также использовать обычные hidden-поля на форме, либо добавлять дополнительные параметры в строке запроса. Однако применение этих методов желательно минимизировать по причинам безопасности. hidden-поля можно использовать для обмена несекретной информацией между кодом, выполняемым на сервере, и скриптом, выполняемым на клиенте. Параметры в строке запроса можно применять для передачи информации между различными страницами. Также неоспоримым достоинством является то, что пользователь может внести страницу вместе с параметрами в список Favorites своего браузера.
Серверные методы
Application
Коллекция StaticObjects является read-only коллекцией, т.е. добавление и удаление элементов в нее в runtime запрещено. Элементы в этой коллекции определяются в файле Global.asax с помощью тега <object runat="server" scope="application">. Например:
Таким образом, в коллекцию добавлен новый объект типа StringBuilder с ключом AppStr.
Использовать его можно либо непосредственно из aspx файла:Отметим еще раз, что этот способ введен исключительно для совместимости с предыдущими версиями ASP и использовать его в данный момент не рекомендуется.
Во избежание ситуации deadlock блокировка автоматически снимается в таких случаях: после успешного выполнения запроса, после ошибки тайм-аута соединения либо после любого неперехваченного исключения, возникшего в процессе обработки запроса пользователя.
Одним из недостатков Application является неограниченное время жизни его объектов. Т.е. значения, записанные в эту коллекцию, будут в ней существовать до тех пор, пока они не будут явно удалены (методы Remove, RemoveAll, RemoveAt, присвоение null).
В противном случае они будут существовать до завершения работы приложения либо перезагрузки веб-сервера. С другой стороны, при перезапуске веб-сервера уничтожаться все значения Application, что может усложнить жизнь администратора сервера.
Также Application неприменим при развертывании приложения на нескольких физических серверах (web farm). В этом случае у каждого отдельного сервера будет своя собственная коллекция, что в целом приведет к рассинхронизции.
Session
При поступлении запроса от пользователя, у которого нет соответствующего Cookie или он не имеет SessionID в URL запроса, инициируется создание новой сессии. При этом происходит генерация нового уникального SessionID. После чего возникает событие Session_Start веб-приложения.
Сессия существует до тех пор, пока пользователь работает с веб-приложением и еще немного после. Для этого в настройках аппликации выставляется таймаут сессии, который по умолчанию составляет 20 минут. Т.е. если пользователь в течение 20 минут не совершил ни одного запроса к приложению, то сессия этого пользователя уничтожается. При этом возникает событие Session_End приложения.
Также как Application, для совместимости с предыдущими версиями ASP, контейнер включает в себя две коллекции Contents и StaticObjects. Для доступа к Contents можно либо использовать одноименное свойство, либо индексатор Session. Например:
Коллекция StaticObjects является read-only коллекцией, ее элементы определяются в файле Global.asax с помощью тега <object runat="server" scope="session">. Например:
Использовать его можно аналогично вышеуказанному примеру для Application:
Механизм сессий, в отличие от Application, предоставляет несколько способов сохранения. Какой из них использовать в приложении, определяется атрибутом mode тега <sessionState> в файле web.config. Этот атрибут может принимать пять значений:
Off. Сессии отключены, т.е. данные сессии никак не сохраняются.
InProc. Способ, унаследованный от предыдущих версий ASP. Сессия храниться в локальной памяти веб-сервера. В результате при сбое приложения или перезапуске веб-сервера все данные теряются. Это может быть вызвано, например, настройками из тега <processModel> в файле machine.config (либо web.config). Один из возможных сценариев - преувеличение объема памяти, указанного в атрибуте memoryLimit. Поскольку каждый пользователь имеют свою собственную сессию, то увеличение нагрузки на сервер может потребовать достаточно большого объема ресурсов. Также перезапуск может вызвать изменение одного из файлов Global.asax или Web.config, либо директории \Bin приложения.
Этот режим также используют для организации web farm либо отказоустойчивого кластера веб-серверов. Как и в предыдущем способе, сохраняемые объекты должны быть сериализуемы.
Cache
Как и все остальные контейнеры, Cache представляет собой коллекцию типа ключ-значение. В Cache хранятся данные, доступные всем пользователям из всех точек приложения, но за счет использования ключей, специфичных определенному пользователю, его можно использовать для хранения пользовательской информации. Содержимое этого контейнера может сохраняться в течение долго времени, но, к сожалению, теряется при перезапуске веб-приложения или веб-сервера. Характерной особенностью Cache является невероятная гибкость. Он позволяет эффективно хранить любую по объему информацию и содержит механизм устаревания кэшируемой информации в зависимости от ряда условий.
Для каждого значения в Cache можно установить период устаревания информации по времени (абсолютной дате или относительному промежутку времени), либо на основе изменений файла. Также имеется возможность реализовать callback-функцию, которая вызывается при удалении значения из коллекции. Это позволяет проверить не существует ли более свежая версия данных и при необходимости занести ее в коллекцию.
Контейнер поддерживает как стандартный доступ к элементам с помощью индексатора, что показано на примере:
так и ряд других методов. Наиболее используемый из них метод Insert. Он позволяет при записи нового значения в Cache установить период устаревания, зависимость от файла, указать callback-функции и приоритетность информации. Следующие несколько примеров демонстрируют ее использование:
Читайте также: