Dove in una applicazione Web MVC dovrebbero scrivere file localmente?

Question

Dove in una applicazione Web MVC dovrebbero scrivere file localmente?

#1 da (5 voti)
#2 da (0 voti)
#3 da (0 voti)

6

Nella mia applicazione web che utilizza un framework MVC che ha diversi moduli per modelli, viste e controller, parlo con diversi database e API. Questi sono implementati come modelli individuali.

Numerosi dati vengono immessi dall'utente in diverse schermate. Questi dati entrano nella sessione. Alcuni di questi dati sono metainformazioni che convalidano il successo del processo, e alcune sono cose che voglio mantenere. Questi dati dovrebbero essere scritti su un file nel file system e il percorso di quel file con alcune meta-informazioni è memorizzato in un database. Successivamente, verrà visualizzata una pagina di conferma per l'utente.

Ora sto cercando di capire dove inserire la scrittura del sottoinsieme dei dati accumulati nella sessione nel file nel mio formato specifico.

Ci sono diversi pensieri che ho in merito. Non sono sicuro quale sia il più giusto .

Dovrebbe essere una vista perché prende i dati che sono già presenti nella sessione dell'utente e la presenta in un modo specifico: il formato del file (che è XML, ma non è rilevante). La formattazione e la scrittura del file sono implementate lì.

Ragionamento: la vista HTML predefinita che esegue il rendering dei dati come sito Web nel browser dell'utente ha l'interfaccia del server web impostata come canale STDOUT. Allo stesso modo, una vista JSON presenta elementi nel caso in cui venga effettuata una chiamata API. Se scriviamo su un file, lo STDOUT della vista che formatta il file è impostato su un handle locale e noi lo scriviamo.
Ci dovrebbe essere una vista per portare i dati nel mio formato XML, ma un modello per scrivere i dati nel file.

Ragionamento: perché dopo aver scritto il file, verrà visualizzato un altro sito web. Solo una vista può essere alla fine della catena di cose che fanno cose nel corso della vita di una gestione delle richieste. Ma poiché i dati vengono formattati, una vista è appropriata. Semplicemente restituisce i dati formattati invece di scriverli su un sink (STDOUT).
Dovrebbe essere un modello , perché tratta i dati.

Ragionamento: i modelli sono origini dati e sink di dati. Anche se la parte sorgente è assente qui c'è ancora un sink di dati. Anche il fatto che debba essere formattato è neglegabile perché se dovessimo parlare ad es. una API RESTful di qualche tipo dovremmo anche prima formattare i dati come parte di una richiesta GET (che è molto semplice) o forse una rappresentazione JSON come corpo di una richiesta POST / PUT.

Il codice che formatta i dati in XML è già stato creato come classe autonoma che non è ancora legata alla webapp.

La mia domanda è questa: Dove nell'applicazione dovrei usare quella classe e scrivere il file su disco in modo da non rompere il pattern MVC?

Casi esemplificativi dove si verificherà questo processo specifico includono:

un modulo di feedback / sondaggio utente con più pagine, come il sondaggio utente di Overflow dello stack,
una canalizzazione di ordini di e-commerce,
inserimento dati di back-office che comunica con terze parti tramite un'API basata su file dove l'invio avviene in modo asincrono in un momento successivo non correlato

web-applications file-handling mvc

posta simbabque 11.08.2015 - 11:28

fonte

3 risposte

Leggi altre domande sui tag web-applications file-handling mvc

La possibilità di estendere una classe in fase di runtime implica una progettazione scadente? C ++ 11 Funzioni membro Lambda vs Helper

score 5 · Answer 1

Nessuno dei precedenti, in realtà. È responsabilità del controllore scrivere i dati in un file, anche se consiglierei di scrivere una classe specifica per questo e solo che il controller usi quella classe.

Non è una vista perché le viste in MVC riguardano esclusivamente il rendering dei dati nell'interfaccia utente. I dati stessi dovrebbero probabilmente essere inseriti in un modello e tale modello persisteva tramite il controller.

Pensa a questo in modo indipendente dall'archiviazione. Se si tratta di dati archiviati nel database, si farebbe qualsiasi cosa oltre a mettere i dati su un modello e utilizzare un repository (o una sorta di DAL) per scrivere quel modello in un database? Probabilmente no. In questo caso raccoglieresti i tuoi dati in un modello, consegnerai il modello a un repository e poi userai la tua classe di formattazione XML per scrivere il modello in un file.

score 0 · Answer 2

Ho avuto lo stesso problema ma la mia situazione era leggermente diversa, lasciatemi spiegare.

Nel mio progetto ho dovuto usare i file per due scopi:

Memorizza i dati (database)
Traccia errori (file di registro)

Quindi il mio modello era dedicato all'interazione con i file usati come database e ho creato alcuni helper (stavo usando Codeigniter) per scrivere file di log. In questo modo ho potuto invocare le funzioni di aiuto ovunque e questo è stato davvero utile perché ho dovuto tenere traccia degli errori nei modelli e nei controller.

Nel tuo caso ti suggerisco di scrivere la tua classe di supporto per essere invocata dove devi scrivere i dati.

Spero che aiuti

score 0 · Answer 3

In una leggera variazione della risposta di JDT ... se capisco tutto correttamente, questo è il modo in cui lo vedo (scusate il gioco di parole):

Visualizza / Controller : entrambe le parti riguardano la presentazione. Il controller funge da intermediario tra la vista e il modello, influenzando le modifiche al modello (a meno che non si abbia un legame con il modello dalla vista) e riflettendo lo stato del modello nella vista.

Modelli : implementa le regole di business / comportamento o, almeno, fai uso di oggetti che lo fanno. Le regole aziendali vengono utilizzate quando si applicano comandi e query allo stato di applicazione / sessione e si definisce il cuore del comportamento dell'applicazione.

Dati : lo stato dell'applicazione deve essere persistente per essere di qualsiasi utilità, in generale, in modo che i modelli utilizzino un livello dati per ottenerlo.

In questo modo, qualsiasi mutazione dello stato dell'applicazione passa attraverso lo stesso livello di regole aziendali per ottenere consistenza; la presentazione non interagirebbe direttamente con i dati.

Non avrei il controller direttamente responsabile della persistenza perché se dovessi cambiare il livello di presentazione con un altro (dove non hai il controller, come se fosse diventato un servizio headless), tu Ho perso il pezzo che stava facendo la persistenza per te. Spingendola verso il livello aziendale (nei modelli), sei libero di cambiare il livello di presentazione e mantenere il tuo comportamento.