2010-08-13 2 views
4

В asp.net основными хранилищами данных являются приложение, сеанс, а также кеш объектов. Я использовал подсказки/советы для здравого смысла (например, никогда не ставьте в приложение определенные данные, никогда не ставьте неуправляемые ресурсы в сеанс и т. Д.), Но, честно говоря, я никогда не сталкивался с рекомендациями и примерами того, когда использовать то, что в MSDN или от известных фигур, таких как Haack и Gu, которые охватывают все три вместе (например, первый клик Google в MSDN говорит об использовании приложения в качестве глобального кеша, если это так, для чего нужен кеш объекта?Рекомендации по использованию кеша сеанса приложения ASP.net

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

Редактировать: является что я нашел до сих пор: http://msdn.microsoft.com/en-us/library/ff647787.aspx

ответ

2

Использование сеанса для хранения информации о пользователе, поскольку структура автоматически связывает каждое хранилище сеансов с конкретным пользователем.

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

Я не знаю, когда вам когда-либо понадобится объект приложения. Если я не ошибаюсь, объект Application скорее является реликвией классического ASP, чем чем-либо еще.

Другим способом кэширования, который может быть столь же важным, является кэширование по запросу через коллекцию HttpContext.Items. Это позволяет вам кэшировать данные для времени жизни запроса и полезно, если вы продолжаете запрашивать одни и те же данные во время одного запроса (например, из разных элементов управления пользователя на странице). Для получения дополнительной информации об этом подходе см. HttpContext.Items - a Per-Request Cache Store.

0

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

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