In MVC3, dovrei avere modelli "edit" separati rispetto ai modelli "display"?

Question

Con MVC3, dovrei progettare i miei modelli di vista in modo tale che ce ne sia uno che è associato alla vista (DisplayModel) e uno che viene posticipato al controller (EditModel)?

Per chiarire, non sto chiedendo modelli di dati e modelli di vista - So che non è bello legare le mie viste/controller a modelli di dati/dominio.

Né sto chiedendo di condividere un modello attraverso due viste separate, una vista che viene utilizzata per la visualizzazione dei dati e un'altra vista che viene utilizzata per modificare i dati.

Piuttosto, sto chiedendo una vista che viene utilizzata per modificare i dati e il modello che è associato alla vista rispetto al modello associato all'azione del controller.

In altre parole, se questo è il mio punto di vista:

@model MyApp.Models.CustomerModel 

avvisare il controller di azione simile a:

public ActionResult Index(CustomerModel model) 

Oppure:

public ActionResult Index(CustomerEditModel model) 

A un certo punto, siamo stati facendo il secondo (separato). Ma ultimamente, abbiamo iniziato a fare il primo (condiviso).

La ragione di questo cambiamento è stato perché:

1. Con MVC3 convalida discreto, se sto usando DataAnnotations sul mio modello per la validazione, questo è necessario in entrambi i modelli, se sono separati (sul display modello per mappare la convalida lato client e sul modello di modifica per la convalida lato server).

2. Come la nostra applicazione maturata, ci siamo resi conto che i nostri modelli di visualizzazione e modifica erano identiche al 95%, con l'eccezione delle liste di selezione che erano nei nostri modelli vista. Ora li abbiamo spostati su uno shared class e li stiamo passando attraverso la vista ora.

ma ho visto alcune altre discussioni che puntano ad avere modelli condivisi per la vista/regolatore di essere una cattiva idea, e che it violates separazione degli interessi.

Qualcuno può aiutarmi a capire i compromessi per questi due approcci?

Answer 1

Ho visto argomenti perfettamente validi a favore e contro, dipende solo da ciò che funziona meglio per la vostra applicazione. Non esiste una soluzione adatta a tutti che possa essere applicata!

Se non l'hai letto, Jimmy Bogard ha scritto un ottimo post su come il suo team fa MVC here, che copre questo argomento.

Answer 2

Se le proprietà sono le stesse per i modelli di visualizzazione e modifica, non vedo alcun motivo per avere classi separate.

Answer 3

Penso che scoprirai che è incostante, non importa in che direzione vai, ma se puoi intraprendere il percorso di manutenibilità più semplice allora dovresti farlo. Nella mia esperienza, avere un singolo modello è molto più facile da mantenere, ovviamente, ma sembra che ci sia sempre qualche decisione commerciale che mi costringa a dividere i modelli. Se ti trovi in ​​quel 95%, penso che tu sia veramente in forma.La tua applicazione, da una prospettiva di manutenibilità correlata ai tuoi modelli, sarà facile da mantenere. Quando arriva un cambiamento, hai un posto per fare quel cambiamento, per la maggior parte. Il problema che mi sembra sempre di incontrare è quello di ridimensionare i cambiamenti aziendali su più modelli. Copia/incolla problemi, o semplicemente dimenticando qualcosa da qualche parte da qualche parte, sembra sempre farmi male a causa del problema multi-modello.

Answer 4

ci siamo resi conto che i nostri modelli di visualizzazione e modifica erano identici al 95%, con l'eccezione degli elenchi di selezione presenti nei nostri modelli di visualizzazione. Ora abbiamo spostati in una classe condivisa e li stiamo passando attraverso la vista ora.

Sono identici al 95% in dati e operazioni o solo in dati? Ricorda che le classi incapsulano dati e comportamenti.

Se sono simili al 95% nelle proprietà ma hanno operazioni totalmente diverse, è possibile che si divida in due classi. O forse no :)

Come altri hanno sottolineato, non esiste una risposta adatta a tutti e nel tuo caso sembra che una classe sia OK ... ma se inizi a notare che il comportamento su ciascuno di non è correlato, non aver paura di ripensarti.

Answer 5

Nessuno vista modello per entrambe le direzioni. Mescolarlo non solo è più difficile da seguire, ma è possibile inserire facilmente valori non validi nella pagina che viene automaticamente associata. Potrei sovrascrivere il tuo customerid (o crearne uno) per esempio.

Eredita da un modello di vista di base se è necessario o non fare affidamento sulle annotazioni di dati e utilizzare la auscente api sul modello salvato.

Un grande legame (un po 'estraneo, ma la mappa automatica è bello)

modifica (scusate qualcun altro precedentemente postato qui sotto ho appena realizzato) http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

anche ASP.net MVC - One ViewModel per View or per Action?

Tu (IMHO) dovresti essere generalmente vincolante per VieWModel specifico del tuo metodo piuttosto che come modello di visualizzazione condiviso. Potresti rimanere intrappolato in una trappola di proprietà mancanti, ecc. Ma potrebbe anche funzionare bene per te.

Usa auto mapper per andare tra entrambi. Jimmy ha anche un simpatico attributo AutoMap quando si torna alla vista. Tornando indietro, non userei un CustomerModel in generale in quanto potrebbero esserci dei campi richiesti che non provengono dal mio modo di dire, creare una vista. Ad esempio, un ID cliente potrebbe essere un campo obbligatorio e per un'azione "crea" non sarà presente. Ma se trovi nella maggior parte dei tuoi casi questo per funzionare davvero per te, allora non c'è alcuna ragione per non usarlo.

Answer 6

Sono d'accordo con rich.okelly's answer che non esiste un approccio corretto.

Ci sono un paio di problemi che ho con l'utilizzo di un modello, però.

Sarà molto utile utilizzare sempre un modello senza avere proprietà non necessarie quando la vista deve visualizzare un elenco di oggetti selezionabile. Il modello dovrà avere l'elenco di oggetti e una proprietà per accettare il valore POST che l'utente sceglie. Queste proprietà non necessarie aggiungono una piccola quantità di confusione e sovraccarico di codice. (Un modo per aggirare questo è di avere il modello di contenere ID unico selezionato e hanno aiutanti HTML per costruire le liste.)

Un'altra preoccupazione è più legato alla sicurezza. Uno scenario comune è la visualizzazione di informazioni in un modulo che dovrebbe essere considerato di sola lettura. Nel caso di un ViewModel e un EditModel, EditModel conterrà solo le proprietà che si prevede vengano POST, mentre ViewModel conterrà tutte le proprietà. Ad esempio, se un modulo visualizza lo stipendio di un utente, un utente sarà in grado di pubblicare un "salario" e farlo associare automaticamente alla proprietà Salario di ViewModel da MVC. A questo punto, è necessario eseguire something per assicurarsi che non finisca nel database. Potrebbe essere se la logica/else, un attributo Bind, la logica di Automapper o qualcos'altro, ma il punto è che si tratta di un passaggio che potrebbe essere trascurato. Quando si considera la durata di un'applicazione, mi piace la chiarezza di EditModel nel tempo.

Queste preoccupazioni non significano che due modelli sono buoni e un modello è cattivo, ma devono essere considerati quando si sceglie un progetto.