Управление состояниями ASP.NET в соответствующих ситуациях
Существует 6 методов управления состояниями в ASP.NET 3.5 (насколько я знаю).
(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
Может ли кто-нибудь дать мне подходящие примеры ситуаций, когда я должен использовать эти методы?
Например:
(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.
Ответы
Ответ 1
Вариант управления государством
Просмотр состояния:
Используйте, когда вам нужно хранить небольшие объемы информации для страницы, которая будет отправляться обратно в себя. Использование свойства ViewState обеспечивает функциональность базовой безопасности.
Состояние управления:
Используйте, когда вам нужно хранить небольшие объемы информации о состоянии для управления между общими поездками на сервер.
Скрытые поля:
Используйте, когда вам нужно хранить небольшие объемы информации для страницы, которая будет отправляться обратно на себя или на другую страницу, и когда безопасность не является проблемой.
Вы можете использовать скрытое поле только на страницах, которые отправляются на сервер.
Печенье:
Используйте, когда вам нужно хранить небольшие сведения о клиенте, а безопасность не является проблемой.
Строка запроса:
Используйте, когда вы переносите небольшие объемы информации с одной страницы на другую, и безопасность не является проблемой.
Строки запроса можно использовать только в том случае, если вы запрашиваете одну и ту же страницу или другую страницу по ссылке.
Параметры управления сервером
Состояние приложения
Использовать при хранении редко изменяемой глобальной информации, которая используется многими пользователями, и безопасность не является проблемой. Не храните большое количество информации в состоянии приложения.
Состояние сеанса
Используйте, когда вы храните краткосрочную информацию, относящуюся к отдельному сеансу, и проблема безопасности. Не храните большое количество информации в состоянии сеанса. Имейте в виду, что объект состояния сеанса будет создан и сохранен для жизни каждого сеанса в вашем приложении. В приложениях с множеством пользователей это может занимать значительные ресурсы сервера и влиять на масштабируемость.
Свойства профиля
Используйте, когда вы храните информацию о пользователе, которая должна сохраняться после истечения срока действия пользовательского сеанса, и ее необходимо снова получить при последующих посещениях вашего приложения.
Поддержка базы данных
Используйте, когда вы храните большое количество информации, управляете транзакциями или информация должна выдерживать перезагрузку приложений и сеансов. Углубление данных вызывает озабоченность, и проблема с безопасностью.
Ответ 2
На это может повлиять множество факторов, поэтому я не буду комментировать их все. Но вот несколько указателей:
-
ViewState
- Это полезно, когда вы будете регулярно отправлять сообщения на одну и ту же страницу (что вы фактически вынуждены делать с помощью ASP.Net Webforms). Насколько это полезно, это зависит от того, какое приложение вы создаете. Для общедоступных интернет-сайтов его следует использовать очень экономно. Вы даже можете отключить его по умолчанию. Для локальных сайтов интрасети это отличный инструмент; особенно для менее тяжелых страниц веб-форм.
-
Query String
- Используйте это, чтобы сохранить состояние, которое вам нужно, чтобы позволить пользователю закладок на странице или процесс и вернуться к намного позже. Даже тогда вы можете захотеть сохранить его до какого-то хэша, который вы можете использовать в качестве ключа в поиске базы данных, чтобы избежать действительно огромного URL-адреса (хотя хеши имеют свои проблемы). Кроме того, многие пользователи любят возиться с вашей строкой запроса напрямую, так что опасно слишком много вкладывать здесь. Это легко случайно подвергнуть данные пользователям, которые не должны его видеть таким образом.
-
Application State
- Помните, что это доступно всем пользователям, поэтому используйте его соответствующим образом. Такие вещи, как количество просмотров, могут идти здесь.
-
Cookies
- Не используйте файлы cookie для хранения учетных данных пользователя. Это просто незашифрованные текстовые файлы. Используйте файлы cookie для хранения ключа в сеансе (даже здесь вы можете и должны теперь использовать сеансы без файлов cookie) и простые параметры персонализации, которые будут специфичны для этого пользователя и браузера. Например, размер моего монитора на рабочем месте отличается от домашнего, и поэтому установка параметров размера экрана/макета в куки файл хороша, потому что настройки привязаны к каждому компьютеру, но это не будет нарушать мою безопасность, если кто-то еще прочтет, что информация.
Теперь я хочу выделить эту концепцию из раздела "Строка запроса":
вы можете захотеть сохранить его до какого-либо хэша, который вы можете использовать в качестве ключа в поиске базы данных
Снова хэш имеет свои проблемы, но я хочу отметить, что несколько элементов в моем списке говорят (включая строку запроса) о загрузке данных из клиентского веб-браузера на веб-сервер: ViewState, Query String, 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, если необходимо сохранить грузы свойств.
Основной недостаток CPP заключается в том, что пользователь не может использовать кнопки "Назад" и "Вперед" в этом веб-браузере. Когда пользователь нажимает кнопку "Назад", он хочет отменить все на этой странице и повторить последний. При использовании CPP щелкнуть их через мастер; это поведение невозможно без большого количества "Вы уверены, что хотите повторно отправить blablablabl".
3. Строка запроса
Используйте много. Каждое видимое состояние, которое может достигнуть страница, должно быть доступно по URL-адресу. Люди с программами чтения будут благодарны вам за это. И с помощью строки запроса нет необходимости использовать только javascript-решения.
/url/?page=2 // when doing paging, don't use postback for this
/url/?tab=advanced-search // when having tabs on top of your page
и др.
4. Состояние сеанса
Используйте это для короткоживущих объектов, которые имеют смысл только на этот раз, когда посетитель посещает ваш сайт. Например:
- Какой шаг определенного мастера был достигнут
- Страницы, которые посетил пользователь до
- Малые объекты, которые вы хотите поместить в кеш, но которые связаны с пользователем
Не используйте сеансы, но профили для таких вещей, как:
- Preferences
- Выбранный язык
Потому что эти вещи также имеют смысл в следующий раз, когда пользователь посещает ваш сайт.
5. Состояние приложения
Никогда. Для этого используйте кеш ASP.NET, memcached или любую инфраструктуру кэширования.
6. Cookies
Идентификатор сеанса, идентификатор профиля для аутентифицированных пользователей; пользовательские настройки для анонимных пользователей (все перечисленные во втором списке ниже 4.).