Come mantenere i dati temporanei su più richieste HTTP?

3

Nella nostra applicazione web abbiamo un elenco di domande a cui l'utente deve rispondere. Queste domande sono servite all'utente una alla volta e saranno salvate una volta che l'ultima domanda ha avuto risposta.

Il problema che abbiamo dovuto affrontare è stato il salvataggio di tutti i dati di "aiuto": archiviazione dell'indice dell'ultima domanda, restituzione dell'ultima domanda, restituzione delle domande con risposta per la panoramica, ecc. .

Inizialmente abbiamo memorizzato questi dati ciascuno nella sua sessione. Questo ha funzionato, ma significava anche che avevamo circa 5 diverse variabili di sessione per ogni tipo di elenco di domande e un gruppo di cast. Ho rimosso queste variabili di sessione creando alcuni campi aggiuntivi nel viewmodel e memorizzando viewModel nella sua interezza all'interno di una sessione. Ciò ha fatto sì che i nostri dati temporanei persistessero in tutte le richieste (ogni domanda risolta significava una nuova richiesta), rimosso una grande quantità di sessioni e reso il codice più leggibile.

Un altro esempio di utilizzo: il nostro oggetto utente locale viene sovrascritto a ogni richiesta perché è stato ottenuto da un repository / databasecontext che ha ricreato ogni richiesta (ninject). Ciò significava anche che non potevamo semplicemente mantenere un elenco temporaneo nel nostro utente che contiene le risposte già risposte alle loro risposte, dal momento che sarebbe stata svuotata ogni richiesta. Usando questo approccio possiamo salvare questo elenco nell'oggetto di sessione, scriverlo all'utente locale all'inizio del metodo di azione, eseguire l'azione (salvare una nuova risposta) e poi ottenere questo elenco e scriverlo sul viewmodel. È un po 'una soluzione, ma ci siamo assicurati di poter conservare questi dati.

Credevo che questa fosse una soluzione decente, ma ora uno dei membri del progetto (è un progetto scolastico previsto per domani) ha espresso il suo dubbio su questo metodo e ha detto che era una soluzione molto sporca (non è stata fornita alcuna alternativa).

Utilizziamo ASP.NET MVC 4.

Mi sono avvicinato a questo nel modo giusto? Come dovrei averlo risolto in modo diverso?

    
posta Jeroen Vannevel 18.05.2013 - 17:30
fonte

1 risposta

3

Vai con l'oggetto Session ASP.NET - è stato creato esattamente per "dati temporanei persistenti su richieste HTTP" e sembra che abbia funzionato per te.

I tuoi compagni di progetto dovrebbero riconoscere che una soluzione "sporca" che funziona è meglio di una soluzione "pulita" che non lo è. Lo sviluppo di software nel mondo reale riguarda l'iterazione e il software di spedizione.

15 variabili di sessione sono ok. Se sei preoccupato per le prestazioni, ricorda di non ottimizzare mai prima del tempo. Se sei preoccupato per le astrazioni più pulite, ricorda che puoi memorizzare oggetti strongmente tipizzati in Session.

Il mio suggerimento è di modellare le risposte / i progressi vale a dire una classe e archiviare quello in Sessione .

P.S. spero che la tua presentazione sia andata bene!

    
risposta data 20.05.2013 - 04:58
fonte

Leggi altre domande sui tag