DataTable - это довольно тяжелые объекты, и их не рекомендуется хранить в ViewState или Session.Сценарий, который вы описываете, касается кеширования данных.Итак, почему бы не использовать кэш ASP.NET?
ViewState , хотя он не использует столько памяти на сервере, сколько Session или Cache, он все же требует сериализации / десериализации на сервере, что требуетнекоторое временное использование памяти, в дополнение к предоставлению пользователям большой полезной нагрузки при каждом запросе к серверу или с сервера (просто взгляните на View Source в любом браузере, и вы увидите очень большой скрытый ввод с кодировкой base-64).данные).Если вы не используете шифрование, любой может декодировать эти данные, которые доставляются в каждом запросе, что создает потенциальную проблему безопасности, если какие-либо из этих данных являются конфиденциальными.ViewState также предназначен для небольших объемов данных и, как правило, лучше всего придерживаться основных типов данных, таких как целые и строковые значения.
Session , как правило, тоже не очень хорошая идея, так как для этого также требуетсясериализация / десериализация, которая добавляет дополнительные издержки в дополнение к нагрузке на память на пользователя.Сеанс имеет ограничения памяти , которые уменьшаются на пользователя по мере увеличения числа одновременных пользователей.Данные сеанса не «истекают», пока фактический сеанс не истекает для каждого пользователя, который по умолчанию составляет 30 минут.Сеанс отлично подходит для пользовательских данных, но рекомендуется держать его очень маленьким и снова придерживаться основных типов данных, таких как целые и строковые значения.
Кэш не сериализует никаких данных и является *Размер 1015 * ограничен только из-за разрядности ОС.В 32-битной Windows 2003 у вас есть общий размер пула приложений 800 МБ для работы (1,2 или 1,3 ГБ, если вы используете ключ / 3GB).Под 64-битной версией гораздо больше свободы и ограничений - это реально только то, что вы настраиваете до объема доступной системной памяти.Преимущество кэша состоит в том, что по мере увеличения нагрузки на память, срок действия кэша может истекать, чтобы освободить память для более важных вещей.Вы также можете контролировать, когда срок действия элементов истекает, когда нехватка памяти не является фактором (срок действия не гарантируется).Сделайте дополнительный шаг, и вы можете поместить зависимость кэша от данных в базе данных, если используете SQL Server, позволяя самим данным решать, когда истечет срок действия вашего кэша, обеспечивая свежие данные.
Наконец, часто забывают о Приложение объект может использоваться, но только для тех данных, которые, как вы знаете, могут совместно использоваться пользователями, и их не нужно часто менять (надеюсь, до перезагрузки приложения).
Используйте документацию Microsoftдля ViewState , Session , Cache и Application объектов, чтобы определить наиболее разумное использование каждого из них для вашего конкретного сценария.Сочетание их правильного использования в дополнение к использованию AJAX (чтобы избежать полных обратных возвратов страниц) и сжатия HTTP для уменьшения полезной нагрузки, доставляемой клиенту, может создать очень отзывчивый сайт.
В более сложных сценариях, таких как веб-фермыи балансировка нагрузки, есть дополнительные вопросы для размышления.Вопросы, которые вам нужно будет задать себе, будут такими, как: должен ли быть создан новый сеанс, если пользователь подключается к серверу, отличному от первоначально запрошенного?Должен ли кеш работать независимо от того, какой сервер пользователь использует?Эти вопросы приведут вас к решениям, которые могут изменить место хранения данных.InProc Session более простителен, чем использование, скажем, SQL Server, сервера сеансов, поскольку существуют дополнительные ограничения сериализации.