Перенаправление после сообщения в ASP.NET MVC
Возможно, Вы найдете мой статья о Cedet полезный. Cedet имеет поддержку завершающих тегов, gtags, cscope и других инструментов.
, Но рефакторинг отсутствует. Вы, возможно, должны изучить инструмент Xrefactory (но это не свободно)
5 ответов
Сохраните его в сеансе с некоторым уникальным ключом и передайте ключ как часть URL-адреса. Затем, пока сеанс активен, они могут использовать кнопку «Назад / Вперед» в соответствии с их содержанием, и при этом URL-адрес будет отвечать правильно. В качестве альтернативы вы можете использовать кеш ASP, но я обычно резервирую его для объектов, которые совместно используются пользователями. Конечно, если вы использовали параметры вычисления в качестве ключа и нашли результат в кэше, вы можете просто повторно использовать его.
Я думаю, что перенаправление после публикации имеет гораздо больший смысл, когда полученный URL-адрес является значимым. В вашем случае это будет означать, что все данные, необходимые для расчета, находятся в URL-адресе / controller / result.
/ controller / calculate не будет выполнять расчет, но /controller/result.
Если вы это сделаете, все станет довольно просто: вы хешируете значения, необходимые для расчета, и используете их в качестве ключа для кеша. Если пользователь обновляется, он попадает только в кеш.
Если у вас нет значимого URL-адреса, вы можете отправить сообщение в / controller / index. Если пользователь нажмет F5, расчет начнется снова, но снова поможет кеш с хешем в качестве ключа.
TempData обычно считается полезным для передачи сообщений обратно пользователю, а не для хранения рабочих объектов (обновление пользователя уничтожит содержимое TempData).
Я не знаю более подходящих место, чем сеанс для хранения такой информации. Я думаю, что общая идея состоит в том, чтобы сессия была как можно меньше. Лично я обычно пишу несколько оболочек для добавления и удаления определенных объектов в сеанс. Очистите их вручную, где это возможно.
В качестве альтернативы вы можете сохранить в базе данных, в которой вы регулярно удаляете устаревшие элементы.
Я мог бы перенять аналогичную идею многих банков на их сайтах онлайн-банкинга, используя одноразовые ключи для проверки всех POST-сообщений. Вы можете интегрировать его в html-помощник для форм и в свой уровень обслуживания (например) для проверки.
Допустим, вы хотите опубликовать любой экземпляр формы только один раз. Добавьте в форму руководство. Если форма не отправляет обратно, а данные фиксируются, вы хотите аннулировать guid и перенаправить на действие GET. Если, скажем, форма была недействительной, когда страница отправит ответ, вам понадобится новый (действительный) guid там в форме, ожидающей следующей попытки отправки.
GUID генерируются по мере необходимости и добавляются в таблицу в вашей БД. Поскольку они признаны недействительными (POSTS, успешными или нет), они помечаются в таблице. Вы можете обрезать таблицу до 100 строк или 1000, в зависимости от того, насколько тяжелым будет ваше приложение и сколько отрендеренных, но еще не опубликованных форм у вас может быть одновременно.
Я не очень хорошо настраивал этот дизайн, но думаю, что это может сработать. Это не будет таким неприятным запахом, как TempData, и вы все равно можете придерживаться шаблона PRG.
Помните, что с PRG вы не хотите отправлять новые данные в действие GET в какой-либо временной переменной. Вы хотите запросить его обратно из хранилища данных, в которое он теперь привязан.
Как сказал Майкл, TempData имеет единственную цель -> хранить объект только для одной поездки и только одной поездки. Насколько я понимаю, TempData по сути использует тот же объект сеанса, что и вы, но он автоматически удалит объект из сеанса при следующей поездке.
Придерживайтесь сеанса imho, а не возвращайтесь к TempData.