Perché due classi, visualizza modello e modello di dominio?

Question

So che potrebbe essere negativo utilizzare i modelli di dominio come modelli di visualizzazione. Se il mio modello di dominio ha una proprietà denominata Isadmin e ho un'azione di Crea controller per creare utenti, qualcuno potrebbe alterare il mio modulo e farlo pubblicare un valore di forma Isadmin = True, anche se non ho esportato un tale campo di testo nella mia vista . Se sto usando il legame del modello allora quando ho commesso il mio modello di dominio, quella persona ora sarebbe un amministratore. Quindi la soluzione diventa esponendo solo le proprietà di cui ho bisogno nel modello di visualizzazione e utilizzando uno strumento come Automapper per mappare i valori delle proprietà del mio oggetto modello di visualizzazione di ritorno a quello del mio oggetto modello di dominio. Ma ho letto che l'attributo di bind su una classe può essere usato per istruire il legante del modello quali proprietà dovrebbe e non dovrebbe legare. Quindi qual è davvero la ragione per creare due classi separate (modello di dominio e modello di visualizzazione) che rappresentano la stessa cosa e quindi incorporano sovraccarico di mapparle? È più un problema di organizzazione del codice e, in tal caso, come sto beneficiando?

MODIFICARE

Uno dei motivi più importanti che ho incontrato per un modello di visualizzazione che è separato dal modello di dominio è la necessità di implementare il modello MVVM (basato sul modello PM di Martin Fowler) per la gestione delle UI complesse.

Answer 1

Ho scoperto che mentre il mio modello di dominio mi porta l'85% del modo per avere i campi che desidero, non ha mai coperto il 100% dei valori che desidero dalla mia vista. Soprattutto quando si tratta di autorizzazioni e se un utente dovrebbe o meno avere accesso a determinate parti della vista.

Il concetto di progettazione che tengo di seguire è avere la minor logica possibile nelle mie opinioni. Ciò significa che ho campi nel mio modello di visualizzazione come "CanviewThisfield" o "CandittyField". Quando ho iniziato con MVC, avrei avuto il mio modello di dominio che fosse il mio modello di vista e mi sono sempre imbattuto nello scenario in cui avevo bisogno di solo uno o due campi per rendere la mia vista meno ingombra. Da allora sono andato il Visualizza modello/costruttore di modelli percorso e ha funzionato meravigliosamente per me. Non combatto più il mio codice, ma sono in grado di migliorare il mio modello di vista come ho bisogno senza influire sul modello di dominio.

Answer 2

Un altro buon motivo per avere un ViewModel è un pagamento di grandi set di dati. Potresti passare la vista una serie di persone ( Person[] ) ma metadati come il numero di pagine, il numero della pagina corrente, la dimensione della pagina non apparterrebbe al Person classe.

Pertanto, una PERSONAVIEWMODEL risolverebbe questo problema.

Answer 3

ViewModel contiene solo quei membri richiesti dalla vista. Di solito possono essere pensati come una semplificazione o un "appiattimento" del modello di dominio sottostante.

Pensa a loro in questo modo:

• ViewModel: questi sono i dati appropriati per il rendering su questa vista
• Modello di dominio: queste sono tutte le informazioni di cui la mia applicazione ha bisogno su questa entità per eseguire tutte le sue funzionalità

Ad esempio, la mia classe di ordini ha un membro chiamato cliente che è un composizione Associazione, cioè il mio ordine ha un Cliente. Questo oggetto cliente ha membri come FirstName, LastName, ecc ... Ma come vorrei mostrarlo su una vista "dettagli" dell'ordine o di un elenco di ordini e dei clienti che li hanno messi?

Bene, usando un ViewModel posso avere un OrderListItemViewModel che ha un membro CustomerName e posso mappare la combinazione di FirstName e LastName dall'oggetto cliente a questo. Questo può essere fatto manualmente o molto preferibilmente Automapper o simili.

Utilizzando questo approccio, è possibile avere più modi di vista degli ordini specifici per viste diverse, ad esempio la vista dell'elenco degli ordini potrebbe rendere il nome del cliente in modo diverso alla visualizzazione dei dettagli dell'ordine.

Un altro vantaggio di ViewModels è che puoi ridurre i dati estranei non richiesti dall'oggetto dominio sottostante su una vista, ad esempio se sto visualizzando un elenco di ordini, voglio davvero vedere tutte le informazioni di contatto del cliente, i dettagli di fatturazione, eccetera...? Immagino che dipenda dallo scopo dell'elenco ma, probabilmente no.

Answer 4

A volte è necessario visualizzare i dati in modo specifico (cioè, visualizzare una data nel formato MM/DD/YYYY contro YYYY/MM/DD) e spesso è più facile rendere questa proprietà nella vista e non nel dominio Modello, dove vorresti (o dovresti) avere una mappatura a una colonna nel tuo DB.

Answer 5

devi ricordare che il tuo domain model classes sono usati solo internally; Cioè, non vengono mai inviati al cliente. Questo è ciò per cui vengono utilizzati i tipi di modelli di servizio (visualizza i tipi di modello): rappresentano i dati che andranno avanti e indietro tra il cliente e il tuo servizio.