Имейте в виду, что кэширование в сеансе, если вы используете режим InProc, ограничивает вашу масштабируемость, если ваш код не вернется в БД, когда сеанс пуст. Вы будете вынуждены использовать один сервер или привязать пользователя к определенному серверу.
Если вы используете Session State Server, это не применимо, и если вы используете SQL для хранения состояния сеанса, то использование сеанса для кэширования бессмысленно.
Редактировать
Любые советы по этой теме зависят от вашей конкретной среды. Как вы сказали, очень сложный SQL-запрос может выиграть от кэширования даже при использовании состояния сеанса SQL. Я думаю, что самое важное - это сначала заставить ваше приложение выполнять функции и соответствовать бизнес-требованиям. Затем вернитесь, протестируйте и оптимизируйте приложение для обработки ожидаемой нагрузки.
Редактировать 2
На основании вашего обновления нет, я не думаю, что это правда. В одном из моих приложений ASP.Net я использую состояние сеанса для хранения сложной объектной модели, которую пользователь затем манипулирует и модифицирует. Мы используем AJAX и поэтому у нас много короткого общения с сервером, когда пользователь обновляет объект. Удержание объекта в сеансе было сделано для удобства. Объект выполняет множество настраиваемых вычислений для генерации различных точек данных, поэтому выполнение этого на сервере было идеальным, а не попыткой реплицировать код в servr и в javascript. Кроме того, сохранение его в сеансе позволяет нам очень легко отменить функцию.
И да, я знаю, что мы пожертвовали масштабируемостью, но я приветствую тот день, когда я сижу с моим боссом и объясняю, что у нас проблема, потому что у нас слишком много пользователей (и я знаю, что он тоже).
Так что я думаю, что вопрос в том, почему вы храните данные в сеансе, это для удобства и для обеспечения доступа к временным данным, когда пользователь вошел в систему? Это отличается от хранения его для кэширования. При кэшировании нужно помнить одну вещь: как вы собираетесь очищать кеш? Как вы признаете это недействительным? Я не сеанс состояние построено для обработки этого.
Редактировать 3
В общем, хорошо читаемые данные, специфичные для пользователя, дорогие для загрузки из БД, продолжайте кешировать их в сеансе. Вы можете написать свой код, чтобы, если он не находится в сессии, вы нажали на БД. Имейте хороший маленький вспомогательный класс, который делает это, скрывая его от вашего веб-приложения, что вы даже используете сеанс, и вы должны быть хорошими. Приятно скрывать, где вы храните его из Интернета, если обнаружите, что у вас есть проблемы, у вас есть только одно место, чтобы изменить его.