ASP.NET MVC - TempData - Buona o cattiva pratica

Sto usando il AcceptVerbsmetodo descritto nel post del blog Preview 5 di Scott Gu per gestire le voci del modulo in ASP.NET MVC:

• L'utente riceve un modulo vuoto tramite GET
• L'utente invia il modulo compilato tramite POST alla stessa azione
• L'azione convalida i dati, intraprende l'azione appropriata e reindirizza a una nuova visualizzazione

Quindi non devo usare TempData. Detto questo, ora devo aggiungere un passaggio di "conferma" a questo processo e sembra che richieda l'uso di TempData.

Per qualche ragione, ho un'avversione all'uso TempData: è qualcosa su cui progettare.

È una preoccupazione valida o me la sto inventando?

Penso che i dati temporanei siano un meccanismo che spara e dimentica per avvisare l'utente. È fantastico dare loro un promemoria di qualcosa che hanno fatto di recente, ma esiterei anche a renderlo un passaggio obbligatorio in qualche processo utente. Il motivo è che se aggiornano la pagina, credo che sparirebbe. Beh, immagino di essere anche riluttante a usarlo perché non è ben definito quanto sia affidabile.

Mi chiedo se il problema sia che stai facendo reindirizzare l'azione a un'altra pagina prima del passaggio di conferma. Mi chiedo se invece dopo aver inviato per la prima volta, potresti eseguire un'elaborazione sufficiente per generare la finestra di dialogo di conferma, quindi restituire la pagina originale con la domanda di conferma. Simile a come potresti eseguire la convalida, ad eccezione della regola di convalida che controlla se il passaggio di conferma è stato eseguito (con l'interfaccia utente di conferma nascosta fino a quando non viene superata l'altra convalida).

Non c'è bisogno di avere un'avversione per TempData ... Ma se non usato correttamente potrebbe sicuramente essere indice di cattivo design. Se stai utilizzando URL RESTful, TempData è una best practice per trasferire messaggi dalle tue azioni POST alle tue azioni GET. Considera questo:

Hai un modulo in Prodotti URL / Nuovo. Il modulo Pubblica su Prodotti / Crea, che convalida il modulo e crea il Prodotto, In caso di successo il controller reindirizza a Prodotti URL / 1 e in caso di errore reindirizza a prodotti / Nuovo per visualizzare i messaggi di errore.

Products / 1 è solo l'azione GET standard per il prodotto, ma vorremmo visualizzare un messaggio che indica che l'inserimento è stato un successo. TempData è perfetto per questo. Aggiungi il messaggio a TempData nel Post Controller e inserisci un po 'di logica if nella vista e il gioco è fatto.

In caso di errore ho aggiunto i valori immessi in formCollection e una raccolta di messaggi di errore a TempData in Post Action e reindirizzato all'azione iniziale Prodcuts / New. Ho aggiunto la logica alla vista per popolare gli input del modulo con i valori immessi in precedenza insieme a eventuali messaggi di errore. Mi sembra carino e pulito!

Penso che tu faccia bene a esitare prima di usare TempData. TempData viene archiviato nella sessione e ciò potrebbe avere implicazioni per te se:

1. Al momento non utilizzi le sessioni sul tuo sito
2. Hai un sistema che deve scalare a un throughput elevato, ovvero preferiresti evitare del tutto lo stato della sessione
3. Non vuoi usare i cookie (non so quanto MVC supporti le sessioni senza cookie in questo momento)

Se il tuo sito deve avere un'elevata disponibilità, ci sono ulteriori considerazioni sull'applicazione dello stato della sessione, ma questi sono tutti problemi risolvibili.

Ho un metodo GetModel che prima controlla TempData ["modello"] e lo restituisce. In caso contrario, GetModel carica i dati appropriati dal database.

Salva un carico aggiuntivo dal database quando ho un'azione che deve restituire una vista diversa che richiede gli stessi dati del modello.

Controlla i controller senza sessione in MVC3. Si è scoperto che l'utilizzo della sessione impedisce l'esecuzione parallela delle richieste di un singolo utente e quindi porta a prestazioni ridotte.

Poiché tempdata utilizza la sessione per impostazione predefinita, non sarai in grado di utilizzare questa funzionalità. Puoi passare all'utilizzo dei cookie per tempdata, ma è un po 'imbarazzante (almeno per me). Tuttavia, è ancora più pulito di viewstate, quindi forse non è un grosso problema.

Perché hai una tale avversione? Questa cosa è semplicemente fare il suo lavoro e farlo bene :)

Se non ti piace perché non è fortemente tipizzato, puoi sempre creare un wrapper attorno che ti fornirà un'interfaccia fortemente tipizzata.

È come usare ViewData, il che significa che probabilmente non è un rischio per la sicurezza. Ma preferirei usare ViewData piuttosto che TempData. Controlla qui per un confronto: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

A seconda del design, puoi sempre memorizzare l'utente / carrello o quello che ti serve nei tempdata nel database e avere solo un campo "IsReady" che indica se è completato o meno, rendendolo estensibile per dopo se vuoi prenderlo tieni presente che le persone possono chiudere i loro browser.

Tutte buone risposte, hai dato un'occhiata a questo per passare messaggi.

TempData e Session non sono la migliore idea per le architetture RESTful poiché la maggior parte delle sessioni sono archiviate in memoria. Quindi, quando si desidera utilizzare una server farm, la sessione degli utenti esisterebbe su un server mentre la richiesta successiva potrebbe essere inviata a un altro server.

Detto questo, dai un'occhiata a questo uso di TempData per passare i messaggi qui.

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

Mabye questo potrebbe essere adattato per utilizzare un approccio di stringa di query se utilizzato solo per il reindirizzamento ad altri avvisi di pagina.