Qual è il modo preferito per conservare un file su più richieste in MVC

Potresti usare Sessioni qui ma ha alcuni aspetti negativi. Quella spesso citata è la configurazione di default (in corso) è veloce ma la sessione muore se il pool di app viene riavviato. Per quanto riguarda il codice, ciò significa che in genere è necessario verificare se la sessione non è morta, quindi è possibile gestirla in modo corretto. Questo è abbastanza facile da fare, ma è un po 'sovraccarico.

Il lato negativo più grande è il fatto che il browser condivide una sessione tra tutte le schede, quindi se qualcuno fa qualche normale roba di browser moderno puoi ottenere una grande confusione o almeno stranezze nell'interfaccia utente. Un buon esempio di qualcuno che fa qualcosa di simile sarebbe una compagnia aerea unita - puoi solo guardare uno dei tuoi voli contemporaneamente a causa della contesa della sessione.

L'approccio che prenderò qui è di far caricare il file, riporlo in un posto appropriato, generare un ID per esso e poi tenerlo nella procedura guidata. Quando lo completano, puoi ritirare il file alla fine. Se iniziano 2 in una volta, è facile da gestire. Rimani senza stato.

L'ultima app MVC che ho progettato dovevo tenere un file su più pagine prima che fosse "salvato" (come in qualsiasi momento l'utente potesse annullare). L'ho bloccato in Session e tutto ha funzionato bene da allora. Detto questo, questa funzione non ha molto senso (10 utenti in una volta) quindi non ho dati su come scala.

Mentre il web è stateless e il design MVC si presta ad essere il più apolide possibile, l'unico modo per rendere questo bit stateless è di avere l'utente ad inviare il file con ogni richiesta che ne ha bisogno, e ciò sembra male da una UX lato (oltre a dover gestire scenari come i diversi file che vengono passati).

In generale, tenere aperto un file tra le richieste degli utenti non è una buona idea. Ci sono diversi problemi:

• La sessione può scadere, lasciando il file in un limbo. In un sistema occupato, questo può comportare l'esaurimento degli handle di file.
• Molti contenitori Web di qualità "aziendale" serializzano la sessione su un database quando sono occupati. Non si dice quale lingua si sta usando, ma la classe File Java è stateful e non serializzabile, quindi si ha un problema.
• In un ambiente Web farm, la tua prossima richiesta potrebbe non essere gestita dallo stesso server, quindi il file dovrebbe trovarsi su un'unità condivisa in tutta la farm.
• Se sei sfortunato, molti utenti potrebbero voler accedere contemporaneamente allo stesso file, causando alcuni problemi di sincronizzazione difficili.

Quindi quali sono le opzioni:

• Se il file è di piccole dimensioni, potresti riuscire a memorizzare i dati nella sessione e scriverlo solo sull'invio finale. Ma un file da 10 MB è un po 'grande per questa opzione.
• Piuttosto che un file, è possibile mantenere i dati su un database. Il blocco dei record, le transazioni, ecc. Sono le funzionalità di base dei database, quindi molti dei problemi di sincronizzazione spariscono.

• Esistono modi indipendenti dalla piattaforma per bloccare un file, ma questi sono un po 'arcani. Un approccio consiste nell'utilizzare un secondo file "di blocco" che non contiene nient'altro che l'ID di processo del file "proprietario". Ciò risulta complicato con i client Web, poiché generalmente il contenitore Web utilizzerà un pool di thread per soddisfare le richieste.

• Se sai che utilizzerai sempre la stessa piattaforma, la maggior parte degli OS fornisce semafori specifici della piattaforma e simili. Potresti trovare una libreria per la tua lingua che li supporta.

Personalmente userò un database ...

Utilizza un meccanismo di memorizzazione nella cache che è indipendente dalle query stateless eseguite dall'utente. Allo stesso modo, le connessioni al database sono raggruppate, ovvero non si apre mai una nuova connessione DB a parte la prima volta, ogni successivo "open" recupera in realtà una connessione utilizzata in precedenza da una cache all'interno del driver del client DB.

È necessario determinare un metodo per gestire la vita del file, magari chiudendolo dopo un minuto di inattività, ma consente di trattare ogni accesso del file come un'operazione completamente nuova da ogni richiesta e farlo funzionare in modo accettabile.

Detto questo, il sistema operativo esegue già una quantità di cache dei file in modo che il sistema possa funzionare molto bene se riapri ripetutamente lo stesso file in un breve lasso di tempo (cioè prima che esca dalla cache del sistema operativo) senza doversi preoccupare fare qualsiasi cosa.