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

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

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

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

У вас есть форма по адресу URL Products / New. Форма Сообщает о продуктах / Create, которая проверяет форму и создает продукт. В случае успеха контроллер перенаправляет на URL-адрес Products / 1, а в случае ошибки перенаправляет обратно в продукты / New для отображения сообщений об ошибках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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