Управление состояниями ASP.NET в соответствующих ситуациях

Ответ 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.).