Un enorme ViewModel o (ab) usa il database per ogni vista

Question

Un enorme ViewModel o (ab) usa il database per ogni vista

#1 da (5 voti)

3

Sono in procinto di progettare una struttura di applicazione e attualmente sto pensando a come strutturare il mio front-end asp.net MVC5.

La mia applicazione è simile a una procedura guidata con schede per ogni passaggio. Non è un mago severo in quanto devi completare il passaggio precedente per arrivare al prossimo ma è vicino.

Ci saranno 12 schede / passaggi e ognuna delle schede può contenere (ma non è necessario) fino a cinque sottotabelle (clienti). In una regola del calcolo del pollice penso che potrebbero esserci max 12 tab x 5 client x 15 campi (media ...) = 900 campi sul front-end. Questo è il caso peggiore, ragionevole sarebbe 12x2x10 perché attualmente non ho le specifiche complete per tutti e 12 i passaggi.

La mia domanda è: dovrei tenere questo in un albero enorme ViewModel o dovrei forse salvare ogni passaggio in DB? Quindi costruiscilo da PartialViews o Views autonomi. I dati dovranno essere persistenti in DB ad un certo punto.

Durante l'input avrò bisogno di dati da altri passi, ad esempio - al punto 8 dovrò sapere cosa c'era nel passaggio 3 ecc.

Single ViewModel - Ho tutti i dati pronti a portata di mano in qualsiasi momento, ma come sono le prestazioni, una ricerca rapida mi ha fatto questa domanda SQ .

ViewModels standalone - Avrei bisogno di estrarre dati dal DB su richiesta, che potrebbe essere abbastanza frequente. I dati vengono mantenuti ad ogni passaggio, il che è un vantaggio se si verificano degli errori e i dati non vengono salvati in tempo.

design asp.net-mvc

posta Iztoksson 14.11.2016 - 10:34

fonte

1 risposta

Leggi altre domande sui tag design asp.net-mvc

Versioning API, dove indirizzare API non verificate Chi è il responsabile del posizionamento del flusso?

score 5 · Accepted Answer

I have all data ready on-hand at any time, but how is the performance...
I would need to pull data from DB on-demand, which could be quite often. Data is persisted at each step which is a benefit if errors occur and data is not saved in time...
this is already a requirement. User can close application and continue later.

Sembra proprio che tu sappia cosa dovresti fare, e le ragioni per cui. I dati persistenti man mano che l'utente procede attraverso i passaggi non sta "abusando" del database, specialmente dal momento che i tuoi requisiti impongono di farlo.

Un viewmodel o controller dovrebbe mantenere il focus, non provare a racchiudere tutto. Uno degli usi di queste strutture è quello di evitare una singola entità gigante che rappresenta lo stato globale, perché è poco maneggevole con cui lavorare e spesso si comporta male. Se hai bisogno di dati da precedenti passaggi (ad esempio altri viewmodels), quindi recuperarlo.

Sì, dovrai fare più viaggi sul livello di persistenza, ma non è una brutta cosa. Non preoccuparti di quel costo extra di rete a meno che e fino a quando non hai costruito la cosa e profilata per dimostrare che c'è un problema ed è lì che si trova.