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

Не уверен, имеете ли вы в виду кэш по состоянию приложения.

Объект Cache - отличный способ управлять состоянием всего приложения, например, для записи источника и подсчета доступа к вашему веб-сайту (например, для предотвращения DDOS-атак).

На это может повлиять множество факторов, поэтому я не буду комментировать их все. Но вот несколько указателей:

• ViewState - это полезно, когда вы будете часто отправлять сообщения обратно на одну и ту же страницу (то, что вас практически заставляют делать ASP.Net Webforms). Насколько это полезно, зависит от того, какое приложение вы создаете. Для общедоступных интернет-сайтов его следует использовать очень экономно. Вы можете даже выключить его по умолчанию. Для сайтов локальной интрасети это отличный инструмент, особенно для меньшего количества более тяжелых страниц веб-форм.

• Строка запроса - используйте это для сохранения состояния, которое вам нужно, чтобы позволить пользователю сделать закладку на страницу или процесс и вернуться гораздо позже. Даже тогда, вы можете ограничиться каким-то хешем, который вы можете использовать в качестве ключа при поиске в базе данных, чтобы избежать действительно огромного URL-адреса (хотя у хешей есть свои проблемы). Кроме того, многие пользователи любят возиться непосредственно со строкой запроса, поэтому может быть опасно помещать здесь слишком много. Легко случайно открыть данные пользователям, которые не должны видеть их таким образом.

• Состояние приложения - Помните, что это общие данные для всех пользователей, поэтому используйте их соответствующим образом. Здесь можно найти такие вещи, как количество просмотров.

• Файлы cookie - Не используйте файлы cookie для хранения учетных данных пользователя. Это просто незашифрованные текстовые файлы. Используйте файлы cookie для хранения ключа сеанса (даже здесь вы можете и теперь должны использовать сеансы без файлов cookie) и простые настройки персонализации, которые будут специфичными для этого пользователя и браузера. Например, размер моего монитора на работе отличается от домашнего, поэтому размещение настроек размера / макета дисплея в cookie - это хорошо, потому что настройки применяются для каждого компьютера, но это не поставит под угрозу мою безопасность, если кто-то другой прочитает эту информацию.

Теперь я хочу выделить эту концепцию из раздела «Строка запроса»:

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

Опять же, хеши имеют их собственные проблемы, но я хочу отметить, что несколько пунктов в моем списке говорят (включая строку запроса) о загрузке данных из клиентского веб-браузера на веб-сервер: ViewState, Query String, Cookie и Cross-Page Post. Вы хотите свести к минимуму объем данных, перемещаемых от клиента к серверу. Эта концепция применима ко всем перечисленным по нескольким причинам:

1. Получение данных от клиента медленное для общедоступных интернет-сайтов. Даже широкополосные соединения обычно ограничивают доступную для загрузки пропускную способность. 512 Кбит / с (все еще типичная скорость передачи данных по широкополосной сети во многих областях) - это ничто по сравнению с подключением Gigabit Ethernet (или более быстрым), которое, вероятно, находится между вашей базой данных и вашим веб-сервером. Как бы вы ни думали о запросе к базе данных как о медленном (и так оно и есть), это, вероятно, гораздо лучший способ, чем ожидание тех же данных, которые поступят от клиента.
2. Хранение данных на сервере дешевле. , потому что вы не платите за полосу пропускания, необходимую для передачи ее к клиенту или от него, а пропускная способность часто стоит столько же или больше, чем ваше серверное оборудование.
3. Это более безопасно, потому что если все сделано правильно, даже когда клиент ' компьютер или соединение скомпрометированы, хакер имеет доступ только к хеш-ключу, срок действия которого, вероятно, истечет к тому времени, когда он сможет его расшифровать. Конечно, в случае ошибки он может сразу же использовать этот ключ, поэтому вам все равно нужно быть осторожным.

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

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

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