Devo riutilizzare i modelli di vista in diverse viste?

Question

Ho notato che ho opinioni che richiedono le stesse informazioni come altre. Ma a volte è necessario 5 proprietà del modello di vista e volte solo 2.

Hai quota vista tale modello su molti punti di vista o si crea un distinto modello vista per ogni visualizzazione o forse Preferite un eredità o composizione strategia?

Per me ci sono alcuni svantaggi per i modelli di condivisione vista:

1. principio di minima sorpresa: E 'strano per riempire solo 2 proprietà di 5 di un modello di vista e ottenere un'eccezione di riferimento null, perché don' t voglio interrogare dati aggiuntivi del database. Quando il modello di vista ha 5 proprietà, mi aspetto che siano tutte riempite. Le eccezioni dimostrano la regola.
2. Separazione delle preoccupazioni/Principio della singola responsabilità: il modello di visualizzazione si sovrappone a siti complessi, perché è necessario soddisfare esigenze diverse per ciascuna vista. Se la logica è coinvolta, diventa anche più complessa.

Cosa ne pensi? Come gestisci tali circostanze?

Answer 1

Nel progetto su cui sto lavorando, ogni vista ha il proprio ViewModel, tuttavia abbiamo anche CollectionViewModels, che sono condivisi/referenziati da più modelli di vista.

Pensate: un elenco di fornitori, che deve essere visualizzato in più schermate dell'applicazione e che è associato a una serie di controlli: una casella di riepilogo, una visualizzazione griglia e tutto ciò di cui avete bisogno. Avere un solo ViewModel semplifica la logica di aggiornamento/aggiornamento della lista dei fornitori.

TLDR: Vorrei solo riutilizzare i modelli di visualizzazione, se tutti i casi di utilizzo utilizzano il ViewModel allo stesso modo. Cioè tutti usano le stesse proprietà ecc.

Answer 2

Avrei un ViewModel separato per ogni vista. Le proprietà non utilizzate rendono il codice meno leggibile (perché questa proprietà è presente se non viene utilizzata?). Se si ha la stessa funzionalità per un insieme fisso di proprietà su più viste, potrei vedere usando una classe base che contiene tali proprietà.

Answer 3

Di solito condivido ViewModels. A quanto ho capito, i vantaggi dell'utilizzo dei modelli di vista sono (a) la sicurezza, in quanto le proprietà che dovrebbero essere nascoste sono e (b) la separazione delle preoccupazioni tra i livelli di business e di presentazione. (b) si ottiene allo stesso modo durante la condivisione dei modelli di visualizzazione.

Per quanto riguarda (a), sono raramente in una situazione in cui l'esposizione di una proprietà è un rischio per la sicurezza in un luogo ma non in un altro. Se una proprietà deve essere nascosta, probabilmente deve essere nascosta ovunque. Certo, YMMV, ma questa sembra una domanda abbastanza soggettiva.

Answer 4

Utilizzo Entity Framework con Code First quindi le mie classi di dominio devono rimanere piuttosto rigide dato che verranno mappate su un database sql.

Alcune visualizzazioni utilizzano solo un'entità mappata direttamente e ciò è semplicemente eccezionale, quindi utilizzo la stessa entità del dominio. Se tale entità richiede più informazioni (ad esempio due campi password) userò la composizione. "La composizione dovrebbe essere preferita rispetto all'ereditarietà", quindi se puoi usare la composizione, in genere, dato che si tratta di proprietà aggiuntive, è possibile utilizzare la composizione.

Se è presente una schermata che utilizza solo due proprietà di tale entità o si desidera nascondere le proprietà a causa di problemi di sicurezza, creo un nuovo modello di visualizzazione e recupererò solo i dati necessari. Riutilizzerò i modelli di visualizzazione ma solo se sono richieste le stesse proprietà in quell'altra vista.

Answer 5

Le persone tendono ad avere filosofie diverse di ViewModels in base alla loro prospettiva di utilizzo. I ViewModels sono la colla tra una vista e un modello e le persone basano tipicamente la loro risposta su quale delle due estremità preferiscono essere più rigide.

• Se vi piacciono gli oggetti del modello/dati per essere più rigido, quindi si tende a legare il ViewModel più vicino al modello/dati — cioè avrete una sola ViewModel che viene utilizzato in molteplici punti di vista e lasciare che ViewModel determini quali proprietà recuperare in base a come si desidera gestire il caricamento dei dati (e rinviare cose come immagini o altre proprietà a lungo carico, ecc.).
• Se ti piace che le tue viste siano più rigide, legherai ViewModel alla vista — ad esempio, hai un ViewModel separato per ogni vista e lascia che gli oggetti model/data gestiscano cose come la sincronizzazione mentre ti sposti dalla vista a vista.

Personalmente, preferisco il primo come il mio di dati tende ad essere più rigido perché è meno propensi a cambiare rispetto le opinioni sono (in miei progetti — Non credo che sia una proprietà universale dei dati e punti di vista). Poiché le notifiche di modifica sono una caratteristica naturale di ViewModels, non è necessario che i miei oggetti modello comunichino le modifiche se un utente ha due viste in alto che mostrano dati uguali o simili.

Answer 6

Definitivamente un ViewModel per View, imho.

Man mano che la tua applicazione cresce in complessità, ViewModels tende a crescere e non è bello passare un oggetto con 50 proprietà a una vista quando tutto ciò di cui ha bisogno è una proprietà.

Inoltre, a volte è possibile aggiungere ulteriori proprietà nel ViewModel che sono assolutamente specifiche per la propria vista e che non sono necessarie in altre viste. Supponiamo tu abbia una classe CSS che dipende dalle proprietà di ViewModel. Invece di scrivere le istruzioni if ​​else nella tua vista, crei una proprietà nel ViewModel che restituisce la classe css corretta in base alle regole di business che hai. In questo modo rendi il View il più snello possibile e con un ViewModel dedicato non stai condividendo il nome di una classe CSS con Views a cui non interessa molto.

Answer 7

Vorrei condividere una VM tra più viste solo se tutte le proprietà variabili e metodi sono usati da tutte le viste altrimenti userei l'ereditarietà e il modello di vista di base astratto e se questo non risolve. Da 1 a 1