Парамон, +1

ShSerge2 Парамон и МСУ. А примерчики имеются, когда сессия - зло? Достаточно словами, а не кодом. Таки прочухаем.
Факта, что отжираются серверные ресурсы - мало?

Чтож, вот другой пример, как раз в разрезе сабжа.

1. Имеем 2 формы, F1 и F2.
2. Задача: передать объект из F1 в F2 через сессию.
3. Записываем объект в сессию и идем на форму F2.
4. По каким либо причинам F2 недоступна, либо ошибка HTTP, либо куча причин того, что не получилось подчистить сессионную переменную.

Что в итоге? Правильно, "битый" ресурс.

Я ответил? Теперь я задам вопрос. ShSerge, в чем Вы видите сложность работать "по-правильному", через Url?
В случае, когда объект большой, можно:
a) сжимать объект через тот же deflatestream
б) хранить его в базе

Результат: не грузим сервер.

P.S. Для случаев, если с сайтом / порталом работает 1 пользователь-бабушка, я с Вами согласен: пихаем в сессию, что ни попадя.

ShSerge, еще один вариант в пользу url. Попали на форму F2: произошел ресайкл пула, пользователь отошел и сессия умерла и т.д. В итоге - мы потеряли объект. В случае url - всё хорошо.

ShSergeМСУShSerge, еще один вариант в пользу url. Попали на форму F2: произошел ресайкл пула, пользователь отошел и сессия умерла и т.д. В итоге - мы потеряли объект. В случае url - всё хорошо.
Ну это - да. Правда, только в том случае, если Вы не логинитесь к сайту. А так-то, всё равно всё помрёт, как не передавай.
Почему это? ReturnUrl же.

Руководство MICROSOFT по проектированию архитектуры приложений Управление сеансами

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

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


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


Если используется один Веб-сервер, требуется обеспечить оптимальную производительность обработки состояния сеанса и число параллельных сеансов невелико, храните состояние внутри процесса. Однако если воссоздание данных сеанса чрезвычайно ресурсоемко и требуется обеспечить длительное хранение данных в случае перезапуска ASP.NET, используйте сервис состояния сеанса, выполняющийся на локальном Веб-сервере. Для сценариев с использованием множества серверов (Веб-фермы), где требуется централизованное хранение данных сеансов серверов, используйте хранилище состояния SQL Server.


Если данные состояния хранятся на отдельном сервере, защитите канал связи для передачи состояния сеанса с помощью таких техник, как SSL или IPSec.


Для снижения затрат на сериализацию отдавайте предпочтение базовым типам при хранении данных сеансов.