Долгосрочное использование и конфликт Session / TempData

У меня есть веб-приложение MVC3, которое использует сеанс "в процессе" по умолчанию. У меня есть шаблон PRG - то есть во время обратной передачи, если мое состояние модели недействительно, я сохраняю модель в TempData и перенаправляю на исходное действие получения. В действии получения я извлекаю данные модели (если они существуют) и отправляю в представление. Я считаю, что это один из основных аспектов MVC.

Я узнал, что TempData в фоновом режиме — это переменная сеанса, которая используется при переходе PRG. Мне нужно знать, возможен ли конфликт или перекрестная ссылка, если я использую что-то вроде TempData["model"] на двух страницах и получаю доступ к страницам одновременно. Будет ли это перезаписывать общие данные в TempData["model"] или безопасно, если я использую одни и те же имена tempdata на двух разных страницах.

И конфликтует ли это с данными типа Session["model"]? Я столкнулся с неожиданным повреждением данных сеанса - возможно, из-за моего внутреннего кода, который сбрасывает данные сеанса или что-то еще. Возможно ли, что данные сеанса могут быть частично повреждены? Я имею в виду, что Session["data1"] в порядке, но Session["data2"] больше нет?

Мои пользователи часто используют веб-приложение в течение длительного времени, что приводит к тайм-ауту сеанса. Я попытался использовать службу состояния сеанса ASP.Net для сеанса, но это вызвало проблемы с производительностью, поскольку я храню некоторые тяжелые объекты (через сериализацию) в сессия. Итак, наконец, я вернулся к исходному умолчанию в режиме процессов.

Пожалуйста, поделитесь, если у вас был подобный опыт.


person Hemant Tank    schedule 13.03.2013    source источник
comment
Сессия всегда темпераментна из-за нехватки времени. TempData[model] не должен конфликтовать с вашей Session[model], однако TempData можно использовать только один раз. ViewBag допускает повторное использование. Раньше мне приходилось иметь дело с сохранением данных сеанса обратно в БД, и это приводило в ярость. Обычно лучшая идея состоит в том, чтобы ваши пользователи быстро входили и уходили, а не позволяли им отвлекаться на полпути в процессе. Просто мысль.   -  person IyaTaisho    schedule 13.03.2013
comment
Можете ли вы поделиться соответствующим кодом? почему вам нужно хранить данные в TemData и передавать их в действие GET? вы можете просто добавить ошибку модели и вернуть ее в представление...   -  person Rafay    schedule 13.03.2013
comment
Шаблон PRG необходим, потому что я не хочу дублировать код, такой как выпадающий источник данных, аутентификация и т. д. Мое использование TempData ограничено во время перенаправления на запрос на получение. В моем коде есть некоторые другие вещи, которые могут не сработать. Я просто хотел знать, может ли TempData работать со сбоями в случае двух параллельных запросов.   -  person Hemant Tank    schedule 14.03.2013


Ответы (1)


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

Возможно, вы захотите взглянуть на http://brockallen.com/2012/06/11/cookie-based-tempdata-provider/

person twomm    schedule 25.10.2013