Рекомендации по управлению состоянием ASP.NET

Статья
10/22/2014

Обновлен: Ноябрь 2007

Управление состоянием представляет собой процесс, позволяющий отслеживать состояние и сведения о странице с помощью нескольких запросов к одним и тем же или разным страницам. Как и в случае любой технологии, основанной на HTTP, веб-формы не имеют состояния, т. е. не показывают автоматически, приходит ли вся последовательность запросов от одного клиента, и даже не указывают, продолжает ли один экземпляр обозревателя активно просматривать страницу или веб-узел. Более того, страницы удаляются и создаются заново после каждого цикла обработки на сервере, в результате чего сведения о странице сохраняются только на протяжении жизненного цикла отдельной страницы. Дополнительные сведения о круговых путях и жизненном цикле страниц веб-форм см. в разделе Общие сведения о жизненном цикле веб-страниц ASP.NET.

ASP.NET предлагает несколько способов отслеживать состояние в промежутках между круговыми путями сервера. Выбор того или иного параметра будет зависеть от приложения и должен быть основан на следующих критериях:

Какой объем информации необходимо сохранить?
Клиент принимает постоянные или хранимые в памяти файлы Cookie?
Информация должна храниться на клиенте или на сервере?
Является ли информация уязвимой?
Каковы критерии производительности и пропускной способности для приложения?
Каковы возможности веб-обозревателей и целевых устройств?
Требуется ли сохранение информации для каждого пользователя?
Как долго необходимо хранить информацию?
Обслуживается ли приложение веб-фермой (несколькими серверами), веб-садом (несколькими процессами на одной машине) или одним процессом?

Параметры управления состоянием на стороне клиента

При сохранении сведений с помощью параметров на стороне клиента ресурсы сервера не используются. Эти параметры обычно предоставляют минимальную защиту, однако производительность сервера остается высокой, т. к. ресурсы сервера практически не используются. Однако поскольку для сохранения сведений их необходимо отправить клиенту, существует ограничение объема сохраняемой таким способом информации.

ASP.NET поддерживает следующие параметры управления состоянием на стороне клиента:

Состояние представления
Состояние элемента управления
Скрытые поля
Файлы Cookie
Строки запроса

Состояние представления

Страницы веб-форм предоставляют свойство ViewState в качестве встроенной структуры, автоматически сохраняющей значения для нескольких запросов одной страницы. Состояние страницы сохраняется в скрытом поле на странице. Дополнительные сведения см. в разделе Общие сведения об управлении состоянием ASP.NET.

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

Преимущества использования состояния представления:

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

Недостатки использования состояния представления

Вопросы производительности. Поскольку состояние отображения сохраняется на самой странице, при сохранении больших значений процесс отображения и отправки страницы может замедлиться. Особенно это касается мобильных устройств, чья пропускная способность часто ограничена.
Ограничения устройств. В мобильных устройствах емкости памяти может оказаться недостаточно для сохранения большого объема данных о состоянии представления.
Потенциальные риски безопасности. Состояние представления сохраняется в одном или нескольких скрытых полях страницы. Хотя режим отображения сохраняет данные в хэшированном формате, они могут быть прочитаны. Сведения в скрытом поле можно увидеть, если источник выходных данных страницы просматривается напрямую, что создает потенциальную угрозу безопасности. Дополнительные сведения см. в разделах Безопасность веб-приложений ASP.NET и Основные методы обеспечения безопасности веб-приложений.

Состояние элемента управления

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

Преимущества использования состояния элемента управления:

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

Недостатки использования состояния элемента управления:

Требуется программирование. Поскольку инфраструктура страницы ASP.NET обеспечивает основу для управления состоянием, состояние элемента управления является настраиваемым механизмом сохранения состояния. Чтобы воспользоваться всеми возможностями состояния элемента управления, необходимо написать код для сохранения и загрузки этого состояния.

Скрытые поля

Чтобы отслеживать состояние страницы, специфичные для нее сведения можно сохранять в скрытом поле на самой странице. Дополнительные сведения о скрытых полях см. в разделе Рекомендации по управлению состоянием ASP.NET.

При использовании скрытых полей лучше всего сохранять небольшие объемы часто изменяемых данных на стороне клиента.

Примечание.
При использовании скрытых полей следует отправлять страницы на сервер с помощью метода HTTP POST, а не запрашивать страницу с помощью ее адреса URL (метода HTTP GET).

Преимущества использования скрытых полей:

Не требуются ресурсы сервера. Скрытое поле сохраняется на странице и считывается с нее.
Широкая поддержка. Практически все обозреватели и клиентские устройства поддерживают формы со скрытыми полями.
Простая реализация. Скрытые поля представляют собой стандартные элементы управления HTML, которым не требуются сложные программные алгоритмы.

Недостатки использования скрытых полей:

Потенциальная угроза безопасности. Скрытое поле может быть подделано. Сведения в скрытом поле можно увидеть, если источник выходных данных страницы просматривается напрямую, что создает потенциальную угрозу безопасности. Можно вручную зашифровывать и расшифровывать содержимое скрытого поля, но для этого потребуется дополнительное программирование и затраты. Если безопасность необходима, следует подумать об использовании серверного механизма сохранения, чтобы конфиденциальная информация не отправлялась на сторону клиента. Дополнительные сведения см. в разделах Безопасность веб-приложений ASP.NET и Основные методы обеспечения безопасности веб-приложений.
Простая архитектура хранилища. Скрытые поля не поддерживают сложные типы данных. Скрытые поля содержат поле с одним строковым значением, в которое помещается информация. Для сохранения нескольких значений необходимо реализовать разделенные строки и код, анализирующий эти строки. Можно вручную выполнять сериализацию и десериализацию сложных типов данных в скрытые поля и из них соответственно. Однако это потребует дополнительного программирования. Если необходимо использовать сложные типы данных на стороне клиента, следует подумать об использовании состояния представления вместо скрытых полей. Состояние представления имеет встроенную сериализацию и хранит данные в скрытых полях.
Вопросы производительности. Поскольку скрытые поля сохраняются на самой странице, при сохранении больших значений процесс отображения и отправки страницы может замедлиться.
Ограничения размера хранилища. Если объем данных в скрытом поле становится слишком большим, то некоторые прокси-серверы и брандмауэры будут запрещать доступ к странице, содержащей эти данные. Поскольку максимально допустимый объем может меняться в зависимости от реализаций брандмауэров и прокси-серверов, большие скрытые поля могут вызывать периодические проблемы. Если необходимо сохранять много элементов данных, следует рассмотреть следующие сценарии:
- Поместить каждый элемент в отдельное скрытое поле.
- Использовать состояние представления с включенным фрагментированием, что автоматически будет распределять данные по нескольким скрытым полям.
- Вместо сохранения данных на стороне клиента использовать сохранение данных на сервере. Чем больше данных отправляется клиенту, тем медленнее будет реагировать приложение, потому что обозревателю придется загружать или отправлять больше данных.

Файлы Сookie

Файлы Сookie удобно использовать для хранения небольших объемов часто изменяемой информации на стороне клиента. Эта информация отправляется на сервер вместе с запросом. Дополнительные сведения о создании и чтении файлов Сookie см. в разделе Общие сведения о файлах Cookie ASP.NET.

Преимущества использования файлов Сookie:

Настраиваемые правила срока действия. Срок действия файла Сookie может закончиться сразу после окончания сеанса обозревателя, или же Сookie может храниться на клиентском компьютере неопределенный срок, подчиняясь правилам срока действия на стороне клиента.
Не требуются ресурсы сервера. Файл Сookie сохраняется на стороне клиента и считывается сервером после отправки.
Простота. Файл Cookie представляет собой облегченную текстовую структуру с простыми парами "ключ-значение".
Сохранность данных. Хотя срок жизни файлов Cookie на компьютере зависит от процессов истечения срока годности на клиентском компьютере и от вмешательства пользователя, в целом файлы Cookie являются более долговременной формой сохранения данных на стороне клиента.

Недостатки использования файлов Сookie:

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

Потенциальная угроза безопасности. Файлы Cookie могут быть взломаны. Пользователи могут управлять файлами Cookie на своих компьютерах, что может вызвать угрозу безопасности или быть причиной сбоя приложения, зависящего от файла Сookie. Кроме того, хотя файлы Cookie доступны только для домена, отправившего их на сторону клиента, хакеры обычно находят способы получить к ним доступ из других доменов на компьютере пользователя. Можно вручную шифровать и расшифровывать файлы Cookie, но для этого потребуется дополнительное программирование, к тому же это может ухудшить производительность приложения, поскольку на шифрование и расшифровку требуется время. Дополнительные сведения см. в разделах Безопасность веб-приложений ASP.NET и Основные методы обеспечения безопасности веб-приложений.

Примечание.
Файлы Cookie часто используются для персонализации, когда содержимое страницы настраивается под конкретного пользователя. В большинстве таких случаев речь идет скорее об идентификации, чем о проверке подлинности. Таким образом, обычно защищается файл Cookie, используемый для идентификации, поскольку в нем сохраняются сведения об имени пользователя, имени учетной записи или об уникальном идентификаторе пользователя (например GUID), которые затем используются для доступа к персонализированной инфраструктуре веб-узла.

Файлы Cookie часто используются для персонализации, когда содержимое страницы настраивается под конкретного пользователя. В большинстве таких случаев речь идет скорее об идентификации, чем о проверке подлинности. Таким образом, обычно защищается файл Cookie, используемый для идентификации, поскольку в нем сохраняются сведения об имени пользователя, имени учетной записи или об уникальном идентификаторе пользователя (например GUID), которые затем используются для доступа к персонализированной инфраструктуре веб-узла.

Строки запроса

Строка запроса включает сведения, добавляемые в конец URL-адреса страницы. Дополнительные сведения см. в разделе Общие сведения об управлении состоянием ASP.NET.

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

Преимущества использования строк запросов:

Не требуются ресурсы сервера. Строка запроса содержится в запросе HTTP для конкретного адреса URL.
Широкая поддержка. Практически все обозреватели и клиентские устройства поддерживают использование строк запросов для передачи значений.
Простая реализация. ASP.NET обеспечивает полную поддержку метода с использованием строк запроса, включая способы чтения строк запроса с помощью свойства Params объекта HttpRequest.

Недостатки использования строк запросов:

Потенциальная угроза безопасности. Информация в строке запроса доступна для просмотра пользователем непосредственно через пользовательский интерфейс обозревателя. Пользователь может сделать закладку на URL-адрес или отправить URL-адрес другим пользователям, тем самым передавая также и данные из строки запроса. Чтобы исключить возможную передачу каких-либо конфиденциальных сведений в строке запроса, следует использовать вместо строк запросов скрытые поля с методом POST. Дополнительные сведения см. в разделах Безопасность веб-приложений ASP.NET и Основные методы обеспечения безопасности веб-приложений.
Ограниченный размер. В некоторых обозревателях и клиентских устройствах существует ограничение длины адреса URL — не более 2083 знаков.

Сводные сведения о методах управления состоянием на стороне клиента

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

Параметр управления состоянием	Рекомендуемое использование
Состояние представления	Следует использовать, когда требуется сохранять небольшие объемы информации для страницы, которая получит ответ на запрос самой себе. Свойство ViewState обеспечивает функциональные возможности с базовой безопасностью.
Состояние элемента управления	Следует использовать, когда требуется сохранять небольшие объемы сведений о состоянии элементов управления в промежутках между круговыми путями на сервере.
Скрытые поля	Следует использовать, когда требуется сохранять небольшие объемы информации для страницы, которая получает ответ на запрос к самой себе или к другой странице; и когда обеспечение безопасности не является важным. Примечание. Скрытые поля можно использовать только на страницах, которые отправляются на сервер.
Файлы Сookie	Следует использовать, когда необходимо сохранять небольшие объемы информации на стороне клиента, и когда обеспечение безопасности не является важным.
Строки запросов	Следует использовать, когда необходимо передавать небольшие объемы информации с одной страницы на другую, и когда обеспечение безопасности не является важным. Примечание. Использовать строки запросов можно только при запросе той же или другой страницы через ссылку.

Параметры управления состоянием на стороне сервера

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

Параметры управления состоянием на стороне сервера, поддерживаемые ASP.NET:

Состояние приложения
Состояние сеанса
Свойства профиля
Поддержка базы данных

Состояние приложения

ASP.NET предоставляет состояние приложения с использованием класса HttpApplicationState в качестве метода сохранения универсальной, специфичной для приложения информации, которая доступна всему приложению. Переменные состояния приложения фактически являются универсальными переменными для приложения ASP.NET. Дополнительные сведения см. в разделе Общие сведения о состоянии приложения ASP.NET.

В состоянии приложения можно сохранять специфичные для данного приложения значения, после чего управление состоянием приложения переходит к серверу. Дополнительные сведения см. в разделе Общие сведения об управлении состоянием ASP.NET.

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

Преимущества использования состояния приложения:

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

Недостатки использования состояния приложения:

Область приложения. Область действия состояния приложения может быть и недостатком. Переменные, сохраняемые в состоянии приложения, являются универсальными только для конкретного процесса, в котором работает приложение, а для остальных процессов приложения значения могут быть другими. Следовательно, в состоянии приложения не следует сохранять уникальные значения или обновлять универсальные счетчики в серверных конфигурациях "веб-сад" и "веб-ферма".
Ограниченный срок жизни данных. Поскольку универсальные данные, сохраняемые в приложении, являются переменными, при удалении содержащего их процесса веб-сервера они будут потеряны; это может произойти при сбое сервера, обновлении или завершении работы.
Ресурсные требования. При использовании состояния приложения необходимо использовать серверную память, что может повлиять на производительность сервера, а также на масштабируемость приложения.

Тщательная разработка и реализация состояния приложения может повысить производительность веб-приложения. Например, если поместить в состояние приложения часто используемый и относительно статичный набор данных, то это может повысить производительность, т. к. общее число запросов к базе данных уменьшится. Однако существует возможность компромиссного решения по проблеме производительности. Переменные состояния приложения, которые содержат большие объемы информации, снижают производительность веб-сервера, т. к. нагрузка на сервер увеличивается. Память, занятая переменными, хранимыми в состоянии приложения, остается занятой до тех пор, пока значение не будет удалено или заменено. Следовательно, лучше всего использовать переменные состояния приложения только для хранения небольших, редко используемых наборов данных. Дополнительные сведения см. в разделе Общие сведения о производительности.

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

ASP.NET предоставляет состояние сеанса, доступное как класс HttpSessionState, в качестве метода хранения специфичной для сеанса информации, видимой только в пределах сеанса. Состояние сеанса ASP.NET определяет запросы, полученные от обозревателя в течение ограниченного периода времени (сеанса), и предоставляет возможность сохранения значений переменных в течение этого сеанса. Дополнительные сведения см. в разделах Общие сведения об управлении состоянием ASP.NET и Общие сведения о состоянии сеанса ASP.NET.

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

Преимущества использования состояния сеанса:

Простая реализация. Состояние сеанса легко в использовании, знакомо разработчикам ASP, совместимо с другими классами .NET Framework.
События сеанса. События управления сеансом могут вызываться и использоваться приложением.
Сохранность данных. Данные, помещаемые в переменные состояния сеанса, могут быть сохранены даже после перезапуска служб IIS или рабочих процессов, т. к. эти данные сохраняются в пространстве другого процесса. Кроме того, данные о состоянии сеанса могут быть сохранены на протяжении нескольких процессов, как, например, в веб-ферме или веб-саде.
Масштабируемость платформы Состояние сеанса можно использовать в конфигурациях с несколькими компьютерами и несколькими процессами, что позволяет оптимизировать сценарии масштабируемости.
Поддержка работы без файлов Cookie Состояние сеанса работает с обозревателями, которые не поддерживают файлы Cookie HTTP, хотя именно с файлами Cookie оно чаще всего используется для идентификации пользователей в веб-приложении. Однако при использовании состояния сеанса без файлов Cookie идентификатор сеанса должен помещаться в строку запроса, что вызывает проблемы с безопасностью, рассматривавшиеся в разделе, посвященном строкам запроса. Дополнительные сведения об использовании состояния сеанса без файлов Cookie см. в разделе Администрирование веб-узлов ASP.NET.
Расширяемость Можно настраивать и расширять состояние сеанса, написав собственного поставщика состояния сеанса. Затем данные состояния сеанса можно сохранить в пользовательском формате данных, воспользовавшись одним из множества механизмов хранения данных, таких как база данных, XML-файл или даже веб-служба. Дополнительные сведения см. в разделе Реализация поставщика хранилища состояний сеансов.

Недостатки использования состояния сеанса:

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

Свойства профиля

ASP.NET предоставляет средство, называемое "свойства профиля", служащее для хранения пользовательских данных. Это средство аналогично состоянию сеанса, за исключением того, что данные профиля не теряются по окончании сеанса пользователя. Средство "свойства профиля" использует профиль ASP.NET, хранимый в постоянном формате и связанный с отдельным пользователем. Профиль ASP.NET позволяет легко управлять сведениями о пользователе без необходимости создания и поддержания собственной базы данных. Кроме того, профиль делает пользовательские сведения доступными с помощью строго типизированного API, доступного из любого места в приложении. В профиле можно хранить объекты любого типа. Профиль ASP.NET обеспечивает систему универсального хранения, что позволяет определять и поддерживать практически любой тип данных, по-прежнему предоставляя данные строго типизированным образом. Дополнительные сведения см. в разделе Общие сведения о свойствах профилей ASP.NET.

Преимущества использования свойств профиля:

Сохранность данных. Данные, помещаемые в свойства профиля, могут быть сохранены даже после перезапуска служб IIS или рабочих процессов, т. к. эти данные сохраняются с помощью внешнего механизма. Кроме того, свойства профиля могут быть сохранены на протяжении нескольких процессов, как в веб-фермах или веб-саде.
Масштабируемость платформы. Свойства профиля можно использовать в конфигурациях с несколькими компьютерами и несколькими процессами, что позволяет оптимизировать сценарии масштабируемости.
Расширяемость. Чтобы использовать параметры профиля, необходимо настроить поставщика профиля. В ASP.NET имеется класс SqlProfileProvider, позволяющий хранить данные профиля в базе данных SQL, но можно также создать свой собственный класс поставщика профиля, который хранит данные профиля в другом формате и посредством другого механизма хранения, например в XML-файле или даже в веб-службе. Дополнительные сведения см. в разделах Поставщики профилей ASP.NET и Реализация поставщика профилей.

Недостатки использования свойств профиля:

Вопросы производительности. В целом свойства профиля медленнее, чем состояние сеанса, поскольку данные хранятся не в памяти, а в хранилище данных.
Необходимость дополнительных конфигураций. В отличие от состояния сеанса, для свойств профиля необходимо значительное количество конфигураций. Чтобы использовать свойства профиля, следует настроить не только поставщика профиля, но еще и все свойства профиля, которые требуется сохранить. Дополнительные сведения см. в разделах Общие сведения о свойствах профилей ASP.NET и Определение свойств профиля ASP.NET.
Сопровождение данных. Свойствам профиля необходимо определенное обслуживание. Поскольку данные профиля сохраняются в не изменяющемся хранилище, необходимо убедиться, что при устаревании данных приложение вызывает соответствующие механизмы очистки, которые предоставляются поставщиком профиля.

Поддержка баз данных

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

Безопасность
Персонализация
Целостность
Интеллектуальный анализ данных

Типичные функциональные возможности веб-узла базы данных с поддержкой файлов Cookie:

Безопасность. Посетитель вводит имя учетной записи и пароль на странице входа на веб-узел. Инфраструктура веб-узла отправляет запрос со значениями входа в базу данных, которая определяет, имеет ли данный пользователь право на использование узла. Если сведения о пользователе проходят проверку в базе данных, веб-узел отправляет на клиентский компьютер допустимый файл Cookie, содержащий уникальный идентификатор данного пользователя. Пользователь получает доступ к веб-узлу.
Персонализация. При наличии сведений о безопасности веб-узел может отличать каждого пользователя путем считывания файла Cookie с клиентского компьютера. Как правило в базе данных веб-узла содержатся сведения о настройках пользователя (который определяется с помощью уникального идентификатора). Эта связь называется персонализация. Веб-узел может определить настройки пользователя с помощью уникального идентификатора, содержащегося в файле Cookie, и отобразить для пользователя информацию, которая соответствует его требованиям и изменяется вслед за изменением настроек пользователя с течением времени.
Целостность. Если веб-узел является коммерческим, может потребоваться сохранять записи транзакций заказов товаров и услуг на веб-узле. Эти сведения могут быть надежно сохранены в базе данных, и к ним можно будет обращаться с помощью уникального идентификатора пользователя. С их помощью можно определить, была ли завершена транзакция заказа, а также задать действия, которые должны выполняться в случае сбоя транзакции заказа. Кроме того, эти сведения можно использовать для информирования пользователя о состоянии заказа, размещенного на веб-узле.
Интеллектуальный анализ данных. В базе данных можно надежно хранить сведения об использовании веб-узла, о посетителях и о транзакциях продуктов. Например, отдел развития бизнеса может использовать эти данные, собранные на веб-узле, чтобы определять товарную специализацию или политику распределения доходов на следующий год. Отдел реализации может анализировать демографические сведения о пользователях веб-узла. Технический отдел и отдел поддержки могут анализировать транзакции и определять области, в которых процесс заказа следует усовершенствовать. Большинство реляционных баз данных уровня предприятия, например Microsoft SQL Server, содержат обширный набор инструментов для проектов с интеллектуальным анализом данных.

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

Преимущества использования базы данных для отслеживания состояния:

Безопасность. Доступ к базам данных требует строгой проверки подлинности и авторизации.
Объем хранения. В базе данных можно хранить любой объем информации.
Сохранность данных. Сведения в базе данных могут храниться в течение любого времени; при этом доступность веб-сервера не оказывает на них влияния.
Устойчивость и целостность данных. В базах данных имеются различные средства поддержки правильных данных, например триггеры, правила целостности, транзакции и т. д. Сохраняя сведения о транзакциях в базе данных (а не в состоянии сеанса, например), можно легко восстанавливать данные после возникновения ошибок.
Доступность Данные, хранимые в базе данных, доступны для множества средств обработки информации.
Широкая поддержка. Существует широкий спектр доступных инструментов работы с базами данных, а также пользовательских конфигураций.

Недостатки использования базы данных для отслеживания состояния:

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

Сводные сведения о методах управления состоянием на стороне сервера

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

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