ASP.NET MVC - TempData - Хорошая или плохая практика

Question

Я использую метод AcceptVerbs, подробно описанный в блоге Скотта Гу в Preview 5, для работы с записями формы в ASP.NET MVC:

• Пользователь получает пустую форму через GET
• Пользователь отправляет заполненную форму через POST на то же действие
• Действие проверяет данные, выполняет соответствующее действие и перенаправляет в новое представление

Так что мне не нужно использовать TempData. Тем не менее, теперь я должен добавить шаг «подтверждения» к этому процессу, и, похоже, требуется использовать TempData.

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

Это вообще действительная проблема, или я это выдумал?

Answer 1

Не нужно иметь отвращение к TempData ... Но если не использовать правильно, это, безусловно, может указывать на плохой дизайн. Если вы используете RESTful URL-адреса, TempData - это лучшая практика для передачи сообщений из ваших действий POST в ваши действия GET. Учтите это:

У вас есть форма на URL Продукты / Новые. Форма «Сообщения для продуктов / Создать», которая проверяет форму и создает продукт. При успешном завершении контроллер перенаправляет на URL-адрес «Продукты / 1», а при ошибке перенаправляет обратно на продукты / «Новый» для отображения сообщений об ошибках.

Products / 1 - это просто стандартное действие GET для продукта, но мы хотим, чтобы отобразилось сообщение о том, что вставка прошла успешно. TempData идеально подходит для этого. Добавьте сообщение в TempData в Post Controller и добавьте логику if в представление и все готово.

При сбое я добавляю значения, введенные в formCollection, и коллекцию сообщений об ошибках в TempData в Post Action, и перенаправляю на первоначальное действие Prodcuts / New. Я добавил логику в представление, чтобы заполнить входные данные формы ранее введенными значениями вместе с любыми сообщениями об ошибках. Мне кажется, это чисто и чисто!

Answer 2

Я думаю, что вам стоит передумать, прежде чем использовать TempData. TempData хранится в сеансе, и это может иметь значение для вас, если:

1. Вы не используете сеансы на своем сайте прямо сейчас
2. У вас есть система, которая должна масштабироваться до высокой пропускной способности, то есть вы бы предпочли вообще избегать состояния сеанса
3. Вы не хотите использовать куки (я не знаю, насколько хорошо MVC сейчас поддерживает сессии без куки)

Если ваш сайт должен иметь высокую доступность, существуют дополнительные соображения относительно применения состояния сеанса, но это все решаемые проблемы.

Answer 3

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

Интересно, проблема в том, что у вас есть действие, перенаправляющее на другую страницу до шага подтверждения. Интересно, если бы после их первой отправки вы могли сделать достаточно обработки, чтобы создать диалоговое окно подтверждения, а затем вернуть исходную страницу с вопросом подтверждения. Аналогично тому, как вы можете выполнять проверку, за исключением того, что правило проверки проверяет, был ли выполнен шаг подтверждения (с скрытым пользовательским интерфейсом подтверждения до тех пор, пока не пройдут другие проверки).

Answer 4

Извлечение бессессионных контроллеров в MVC3. Оказалось, что использование сеанса предотвращает параллельное выполнение запросов одного пользователя и, следовательно, приводит к снижению производительности.

Поскольку tempdata использует сессию по умолчанию, вы не сможете использовать эту функцию. Вы можете переключиться на использование файлов cookie для временных данных, но это немного неловко (по крайней мере, для меня). Тем не менее, он все же чище, чем viewstate, так что, возможно, это не такой уж серьезный фактор.

Answer 5

У меня есть метод GetModel, который сначала проверяет TempData ["model"] и возвращает его. В противном случае GetModel загружает соответствующие данные из базы данных.

Это сохраняет дополнительную нагрузку из базы данных, когда у меня есть действие, которое должно вернуть другое представление, требующее тех же данных модели.

Answer 6

Почему у вас такое отвращение? Эта вещь просто делает свою работу и делает это хорошо :)

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

Answer 7

Это похоже на использование ViewData, то есть, вероятно, это не угроза безопасности. Но я бы предпочел использовать ViewData, чем TempData. Проверьте здесь для сравнения: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

В зависимости от дизайна, вы всегда можете сохранить пользователя / корзину или все, что вам нужно в tempdata в базе данных, и просто иметь поле «IsReady», которое указывает, завершено ли оно или нет, что делает его расширяемым на потом, если вы хотите помнить, что люди могут закрыть свои браузеры.

Answer 8

Все хорошие ответы, вы видели это для передачи сообщений.

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

При этом посмотрите на использование TempData для передачи сообщений здесь.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye это может быть адаптировано для использования подхода строки запроса, если используется только для перенаправления на другую страницу оповещений.