Почему ASP.NET MVC использует состояние сеанса?

Рекомендованная командой ASP.NET использовать кеш вместо сессий, мы перестали использовать сессию из работы с моделью WebForm в последние несколько лет. Поэтому мы обычно отключаем сессию в web.config

<sessionState mode="Off" />

Но теперь, когда я тестирую приложение ASP.NET MVC с этим параметром, оно выдает ошибку в классе.SessionStateTempDataProvider в рамках MVC, он попросил меня включить состояние сеанса, я сделал, и это сработало. Глядя на источник, он использует сессию:

// line 20 in SessionStateTempDataProvider.cs
Dictionary<string, object> tempDataDictionary = 
httpContext.Session[TempDataSessionStateKey] as Dictionary<string, object>; 

Итак, почему они используют сессию здесь? Что мне не хватает?

================================================== ======

редактировать Извините, я не хотел, чтобы этот пост обсуждал сессию против кеша, а скорее в контексте ASP.NET MVC, мне просто интересно, почему сессия здесь используется. В этомСообщение блога Скотт Уотермасиск также отметил, что отключение сессии - это хорошая практика, поэтому мне просто интересно, почему я должен включить ее, чтобы использовать MVC с этого момента.

 Filip Ekberg22 дек. 2008 г., 21:04
Он сказал: «Совет. Отключите состояние сеанса, когда он не используется», редко когда сеансы не используются в аутентифицируемой области.
 Ray22 дек. 2008 г., 20:48
Если я правильно помню, я читал это в выпуске журнала MSDN за сентябрь 2005 года. Может быть, я должен сказать это лучше, но мы просто не используем сессию вообще.
 alexandrul22 февр. 2011 г., 23:05
@ShaneC: исправлено.
 edymtt13 дек. 2012 г., 19:51
Кроме того, можно прочитать статью о состоянии сеанса в журнале MSDN за сентябрь 2005 года.Вот - обратите внимание, что это относится к предварительной версии ASP.NET 2.0
 Filip Ekberg22 дек. 2008 г., 20:44
Не могли бы вы предоставить ссылку, где они говорят «использовать кеш вместо сессий», потому что они на самом деле не предназначены для одного и того же?
 Shane Courtrille22 февр. 2011 г., 21:45
При условии, что ссылка Скотта больше не работает.

Ответы на вопрос(4)

@ ray247, не могли бы вы дать ссылку на это? Session и Cache различаются по своей природе и должны использоваться в зависимости от требований приложения. Например, сохранение пользовательских данных в кеше может привести к нежелательному поведению. Конечно, если вы действительно хотите избежать использования сессии, вы можете предоставить собственную реализациюITempDataProvider интерфейс.

 Ray22 дек. 2008 г., 21:03
Кстати, почему хранение пользовательских данных в кеше может привести к нежелательному поведению? Если вы правильно получили ключ кеша для каждого пользователя, я не вижу, в чем проблема.
 Ray22 дек. 2008 г., 21:00
смотри мой предыдущий комментарий
 Chris Shouts11 янв. 2010 г., 22:15
«По умолчанию приложения ASP.NET хранят состояние сеанса в памяти рабочего процесса, в частности в частном слоте объекта Cache». - MSDN (msdn.microsoft.com/en-us/library/aa479041.aspx)
 Darin Dimitrov22 дек. 2008 г., 21:23
Потому что кеш по определению изменчив. Существуют некоторые ситуации вне вашего контроля, такие как нехватка памяти, в которой кэш может стать недействительным и, таким образом, потерять все данные сеанса.
Решение Вопроса

ниченная форма состояния сеанса, которая будет действовать только до следующего запроса от определенного пользователя. (редактировать В MVC 2+ он длится до следующего чтения.) Цель TempData - сохранить данные, затем выполнить перенаправление и сделать сохраненные данные доступными для действия, на которое вы только что перенаправили.

Использование Session для хранилища TempData означает, что любая распределенная система кэширования, которая уже обрабатывает Session, будет работать для TempData. Избегание использования Session напрямую, когда TempData сделает это, имеет несколько преимуществ. Во-первых, вам не нужно самостоятельно очищать сессию; TempData «истекает» самостоятельно.

 Craig Stuntz07 окт. 2011 г., 05:12
@ricka: ОК, готово.
 RickAndMSFT07 окт. 2011 г., 03:16
Крейг, вы можете отредактировать свой ответ для MVC 2+ (как у вас в комментарии выше). Люди читают ваш ответ и пропускают эту часть
 Santhosh19 нояб. 2009 г., 12:17
как или когда очистится эта сессия ..?
 Chuck Conway30 апр. 2009 г., 22:03
Как это работает в конфигурации круговой веб-фермы? Есть ли способ отключить состояние сеанса / TempData в MVC?
 Craig Stuntz19 нояб. 2009 г., 13:45
Сантозе: в MVC 1, по следующему запросу. В MVC 2 beta +, когда это в следующий раз читать.
 Chuck Conway19 мая 2009 г., 03:09
Состояние сеанса можно отключить, отключив в файле web.config и реализовав интерфейс ITempDataProvider.
 Arnis Lapsa27 июн. 2009 г., 10:15
@Craig Черт возьми. Просто написал вопрос и нашел здесь ответ, когда еще раз проверил наличие дубликатов. Потрачено впустую ~ 15 минут ... xD
 Craig Stuntz30 апр. 2009 г., 23:02
Он работает так же, как сеанс всегда работает на ферме серверов. Это задокументировано в MSDN. Лучший способ - использовать распределенный кеш, но вы также можете использовать «липкие сессии». Что касается отключения сеанса, опять же, как и любое другое приложение ASP.NET. Смотрите MSDN. Тогда просто не используйте TempData. Тем не менее, это все равно что лечить прыщи через обезглавливание.

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

Сессии не являются злом, если вы используете их правильно.

 rsenna13 дек. 2010 г., 19:26
Знайте, что это старый вопрос, но этот ответ (и в меньшей степени все остальные тоже) игнорирует тот факт, что ОП использовалWebFarm инфраструктура, которая подразумевает использование SQL Server (который довольно медленный для этой задачи) или выделенной службы общих сетевых окон (что является проблемой в a **) для сохранения этого сеанса - так что кэширование, вероятно, будет действительно лучшим выбором ,

и MS знала, что в отношении постоянного механизма TempData будет другая школа мысли. Таким образом, по умолчанию они сделали постоянное хранилище SessionState. Но дизайн все еще очень гибкий. На основе потребностей проекта и руководящих указаний по управлению вы можете создать своего собственного поставщика временных данных в соответствии с конкретными требованиями.

Вот несколько указателей на ресурсыTempData

Вот некоторые дополнительные улучшения в реализации TempDataУлучшения TempData

Вот альтернативная реализация с использованием распределенного кэширования MS Velocity.Velocity TempData Provider

Ваш ответ на вопрос