2010-09-06 19 views
5

Mi chiedo come creare correttamente un modello di visualizzazione.Best practice con modelli di visualizzazione ASP.NET MVC

Ad esempio, ho una vista di modifica con alcune caselle di testo e un elenco a discesa.

Devo separare l'elenco a discesa in un nuovo modello di vista o shoud la vista di modifica ha un modello di vista con un elenco per il menu a discesa?

In generale, dovrei separare campi di input speciali in modelli di vista separati?

Quando una vista deve avere più di un modello di visualizzazione e quando no?

risposta

6

Non esiste una regola chiara su come creare e organizzare correttamente i modelli di visualizzazione. La tua domanda è troppo vaga per poter rispondere perché hai fornito troppo poco contesto.

Di solito raggruppo i modelli di visualizzazione in base a blocchi funzionali/parti dello schermo che rappresentano. Quindi, ad esempio, immagina di avere una forma complessa composta da più sezioni/campi come i dettagli di contatto, l'indirizzo di consegna, le informazioni di fatturazione, ecc. Un indirizzo potrebbe essere composto da un menu a discesa street, zip, città e paese. Vorrei creare un modello di visualizzazione indirizzi contenente queste quattro proprietà in modo che possa essere riutilizzato in più viste/viste parziali. Ciò renderà anche più semplice la convalida poiché le proprietà dipendenti saranno raggruppate nello stesso modello di vista, ad esempio per convalidare che il dato zip corrisponde alla città e che la città appartiene al paese selezionato.

Ad esempio, ho una vista di modifica con alcune caselle di testo e un elenco a discesa.

Devo separare l'elenco a discesa in un nuovo modello di visualizzazione o shoud la vista modifica avere uno ViewModel con una lista per la DropDownList?

Direi di no, se quei campi sono in qualche modo funzionalmente correlati.

Conclusione: si dovrà trovare il giusto equilibrio tra avere un modello di vista per campo sullo schermo e avere un modello a vista singola per applicazione.

+0

Riguardo alla creazione di submodelli secondari riutilizzabili che hai menzionato - cosa succede se cambi il tuo indirizzo viewmodel perché dovevi modificarlo per una sola vista specifica - la modifica interesserà altre viste che usano l'indirizzo viewmodel anche se hai indentato per cambiare solo una vista ? – BornToCode

0

È necessario separare l'elenco a discesa nel nuovo modello di vista se si desidera essere riutilizzabili.

0

Generalmente si desidera utilizzare il modello ViewModel se si desidera memorizzare i dati utilizzati dalla vista immessa. Per la logica e i dettagli specifici dell'interfaccia utente, un pattern ViewHelper sarebbe più adatto.

Per alcune discussioni su ViewModel consulta questo articolo. http://theminimalistdeveloper.com/2010/08/21/why-when-and-how-to-use-typed-views-and-viewmodel-pattern-in-asp-net-mvc/

+0

Ho dato un'occhiata all'articolo e mi sto chiedendo perché c'è una directory Model e una directory ViewModel? La direcotry del modello è per i modelli di visualizzazione. La suddetta directory Model assomiglia al modello di dominio/modello di oggetto. Quindi, ciò che hanno fatto è creare un modello di visualizzazione costituito da due oggetti dominio. – Rookian

+0

@Rookian. Sì hai ragione. ViewModel è per ViewModels mentre Model è per i modelli di dominio/business. –

1

Preferisco l'approccio di un modello di vista per vista/vista parziale. Questo è a mio avviso l'approccio migliore se si ritiene che lo scopo unico del modello di vista debba essere quello di modellare la vista. Questo paradigma supporta anche l'uso di viste fortemente tipizzate, fornendo così il controllo degli errori in fase di compilazione per l'associazione del modello di viste e si ottiene il vantaggio aggiuntivo di intellisense. Negli scenari in cui si desidera riutilizzare una logica, trovo che spesso può essere soddisfatta rielaborando la vista in viste parziali e fornendo questi partial con i propri modelli di vista. Va sottolineato che non dovrebbe esistere alcuna logica di dominio nei modelli di vista in quanto appartiene davvero a un modello di dominio.

Problemi correlati