Che cos’è ViewModel in MVC?

Sono nuovo di ASP.NET MVC. Ho un problema nel comprendere lo scopo di un ViewModel.

Che cos’è un ViewModel e perché è necessario un ViewModel per un’applicazione ASP.NET MVC?

È meglio se posso avere un semplice esempio.

Un view model rappresenta i dati che si desidera visualizzare nella vista / pagina, sia che vengano utilizzati per il testo statico o per valori di input (come caselle di testo e elenchi a discesa) che possono essere aggiunti al database (o modificati). È qualcosa di diverso dal tuo domain model . È un modello per la vista.

Supponiamo che tu abbia una class Employee che rappresenti il ​​tuo modello di dominio dei dipendenti e che contenga le seguenti proprietà (identificatore univoco, nome, cognome e data di creazione):

 public class Employee : IEntity { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public DateTime DateCreated { get; set; } } 

I modelli di visualizzazione differiscono dai modelli di dominio in quei modelli di vista che contengono solo i dati (rappresentati dalle proprietà) che si desidera utilizzare sulla vista. Ad esempio, diciamo che vuoi aggiungere un nuovo record dipendente, il tuo modello di vista potrebbe assomigliare a questo:

 public class CreateEmployeeViewModel { public string FirstName { get; set; } public string LastName { get; set; } } 

Come puoi vedere, contiene solo due proprietà. Queste due proprietà sono anche nel modello di dominio dei dipendenti. Perché questo si può chiedere? Id potrebbe non essere impostato dalla vista, potrebbe essere generato automaticamente dalla tabella Employee. E DateCreated potrebbe anche essere impostato nella stored procedure o nel livello di servizio dell’applicazione. Quindi Id e DateCreated non sono necessari nel modello di vista. È ansible visualizzare queste due proprietà quando si visualizzano i dettagli di un dipendente (un dipendente che è già stato acquisito) come testo statico.

Quando si carica la vista / pagina, il metodo di azione di creazione nel controller dei dipendenti creerà un’istanza di questo modello di vista, popolerà tutti i campi se necessario e quindi passerà questo modello di visualizzazione alla vista / pagina:

 public class EmployeeController : Controller { private readonly IEmployeeService employeeService; public EmployeeController(IEmployeeService employeeService) { this.employeeService = employeeService; } public ActionResult Create() { CreateEmployeeViewModel model = new CreateEmployeeViewModel(); return View(model); } public ActionResult Create(CreateEmployeeViewModel model) { // Do what ever needs to be done before adding the employee to the database } } 

La tua vista / pagina potrebbe apparire come questa (supponendo che tu stia utilizzando ASP.NET MVC e il motore di visualizzazione Razor ):

 @model MyProject.Web.ViewModels.CreateEmployeeViewModel 
First Name: @Html.TextBoxFor(m => m.FirstName, new { maxlength = "50", size = "50" }) @Html.ValidationMessageFor(m => m.FirstName)
Last Name: @Html.TextBoxFor(m => m.LastName, new { maxlength = "50", size = "50" }) @Html.ValidationMessageFor(m => m.LastName)

La convalida verrebbe quindi eseguita solo su FirstName e LastName . Usando Fluent Validation potresti avere una validazione come questa:

 public class CreateEmployeeViewModelValidator : AbstractValidator { public CreateEmployeeViewModelValidator() { RuleFor(m => m.FirstName) .NotEmpty() .WithMessage("First name required") .Length(1, 50) .WithMessage("First name must not be greater than 50 characters"); RuleFor(m => m.LastName) .NotEmpty() .WithMessage("Last name required") .Length(1, 50) .WithMessage("Last name must not be greater than 50 characters"); } } 

E con Annotazioni dei dati potrebbe sembrare questo:

 public class CreateEmployeeViewModel : ViewModelBase { [Display(Name = "First Name")] [Required(ErrorMessage = "First name required")] public string FirstName { get; set; } [Display(Name = "Last Name")] [Required(ErrorMessage = "Last name required")] public string LastName { get; set; } } 

La cosa fondamentale da ricordare è che il modello di visualizzazione rappresenta solo i dati che si desidera utilizzare , nient’altro. È ansible immaginare tutto il codice e la convalida non necessari se si dispone di un modello di dominio con 30 proprietà e si desidera solo aggiornare un singolo valore. Dato questo scenario, si avrà solo questo valore / proprietà nel modello di vista e non tutte le proprietà che si trovano nell’object dominio.

Un modello di visualizzazione potrebbe non avere solo dati da una tabella di database. Può combinare dati da un’altra tabella. Prendi il mio esempio precedente sull’aggiunta di un nuovo record di dipendente. Oltre ad aggiungere solo il nome e il cognome, potresti anche voler aggiungere il dipartimento del dipendente. Questo elenco di dipartimenti verrà dalla tabella dei Departments . Così ora hai dati dalle tabelle Employees e Departments in un modello di vista. Sarà quindi necessario aggiungere le seguenti due proprietà al modello di visualizzazione e popolarlo con i dati:

 public int DepartmentId { get; set; } public IEnumerable Departments { get; set; } 

Quando si modificano i dati dei dipendenti (un dipendente che è già stato aggiunto al database) non differirebbe molto dal mio esempio precedente. Crea un modello di vista, chiamalo ad esempio EditEmployeeViewModel . Solo i dati che si desidera modificare in questo modello di vista, come il nome e il cognome. Modifica i dati e fai clic sul pulsante di invio. Non mi preoccuperei troppo del campo Id perché probabilmente il valore Id era nell’URL, ad esempio:

 http://www.yourwebsite.com/Employee/Edit/3 

Prendi questo Id e passa attraverso il tuo livello di repository, insieme con il tuo nome e i valori del cognome.

Quando si elimina un record, normalmente seguo lo stesso percorso del modello di visualizzazione di modifica. Avrei anche un URL, ad esempio:

 http://www.yourwebsite.com/Employee/Delete/3 

Quando la vista viene caricata per la prima volta, ottengo i dati del dipendente dal database utilizzando l’ Id di 3. Quindi visualizzerei semplicemente del testo statico sulla mia vista / pagina in modo che l’utente possa vedere quale dipendente viene eliminato. Quando l’utente fa clic sul pulsante Elimina, vorrei solo utilizzare il valore Id di 3 e passarlo al mio livello di repository. Hai solo bisogno Id per cancellare un record dalla tabella.

Un altro punto, non hai davvero bisogno di un modello di vista per ogni azione. Se si tratta di dati semplici, sarebbe opportuno utilizzare solo EmployeeViewModel . Se si tratta di viste / pagine complesse e differiscono l’una dall’altra, suggerirei di utilizzare modelli di visualizzazione separati per ciascuno.

Spero che questo chiarisca ogni confusione che hai avuto sui modelli di visualizzazione e sui modelli di dominio.

Visualizza modello è una class che rappresenta il modello di dati utilizzato in una vista specifica. Potremmo usare questa class come modello per una pagina di accesso:

 public class LoginPageVM { [Required(ErrorMessage = "Are you really trying to login without entering username?")] [DisplayName("Username/e-mail")] public string UserName { get; set; } [Required(ErrorMessage = "Please enter password:)")] [DisplayName("Password")] public string Password { get; set; } [DisplayName("Stay logged in when browser is closed")] public bool RememberMe { get; set; } } 

Utilizzando questo modello di vista è ansible definire la vista (motore di visualizzazione Razor):

 @model CamelTrap.Models.ViewModels.LoginPageVM @using (Html.BeginForm()) { @Html.EditorFor(m => m);  } 

E azioni:

 [HttpGet] public ActionResult LoginPage() { return View(); } [HttpPost] public ActionResult LoginPage(LoginPageVM model) { ...code to login user to application... return View(model); } 

Che produce questo risultato (lo schermo viene acquisito dopo aver inviato il modulo, con i messaggi di convalida):

Come puoi vedere, un modello di vista ha molti ruoli:

  • Visualizza i modelli documenta una vista comprendendo solo i campi, che sono rappresentati in vista.
  • I modelli di visualizzazione possono contenere regole di convalida specifiche che utilizzano annotazioni di dati o IDataErrorInfo.
  • Visualizza modello definisce come dovrebbe apparire una vista (per gli LabelFor , EditorFor , DisplayFor ).
  • I modelli di vista possono combinare valori da diverse quadro di database.
  • È ansible specificare facilmente modelli di visualizzazione per i modelli di visualizzazione e riutilizzarli in molti luoghi utilizzando gli helper DisplayFor o EditorFor.

Un altro esempio di un modello di vista e il suo recupero: Vogliamo visualizzare i dati utente di base, i suoi privilegi e il nome degli utenti. Creiamo un modello di vista speciale, che contiene solo i campi obbligatori. Recuperiamo i dati da quadro diverse dal database, ma la vista è a conoscenza solo della class del modello di vista:

 public class UserVM { public int ID { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public bool IsAdministrator { get; set; } public string MothersName { get; set; } } 

Recupero:

 var user = db.userRepository.GetUser(id); var model = new UserVM() { ID = user.ID, FirstName = user.FirstName, LastName = user.LastName, IsAdministrator = user.Proviledges.IsAdministrator, MothersName = user.Mother.FirstName + " " + user.Mother.LastName } 

Modifica: ho aggiornato questa risposta sul mio blog:

http://www.samwheat.com/Post/The-function-of-ViewModels-in-MVC-web-development

La mia risposta è un po ‘lunga, ma penso che sia importante confrontare i modelli di vista con altri tipi di modelli comunemente usati per capire perché sono diversi e perché sono necessari.

Per riassumere, e per rispondere direttamente alla domanda che viene posta:

In generale, un modello di vista è un object che contiene tutte le proprietà e i metodi necessari per eseguire il rendering di una vista. Le proprietà del modello di vista sono spesso correlate a oggetti dati come clienti e ordini e inoltre contengono anche proprietà relative alla pagina o all’applicazione stessa come nome utente, nome dell’applicazione ecc. I modelli di vista forniscono un object conveniente da passare a un motore di rendering per crea una pagina html. Uno dei molti motivi per utilizzare un modello di visualizzazione è che i modelli di visualizzazione forniscono un modo per testare alcune attività di presentazione come la gestione dell’input dell’utente, la convalida dei dati, il recupero dei dati per la visualizzazione, ecc.

Ecco un confronto tra i modelli Entity (a.ka. modelli DTO a.ka.), Modelli di presentazione e Visualizza modelli.

Data Transfer Objects aka “Modello”

Un object Data Transfer Object (DTO) è una class con proprietà che corrispondono a uno schema di tabella in un database. I DTO sono nominati per il loro uso comune per lo spostamento dei dati da e verso un archivio dati.
Caratteristiche dei DTO:

• Sono oggetti business: la loro definizione dipende dai dati dell’applicazione.

• Solitamente contengono solo proprietà – nessun codice.

• Utilizzato principalmente per il trasporto di dati da e verso un database.

• Le proprietà corrispondono esattamente o strettamente ai campi su una tabella specifica in un archivio dati.

Normalmente le tabelle del database sono normalizzate, pertanto anche le DTO sono normalmente normalizzate. Questo li rende di uso limitato per la presentazione dei dati. Tuttavia, per alcune semplici strutture di dati spesso funzionano abbastanza bene.

Ecco due esempi di come potrebbero apparire i DTO:

 public class Customer { public int ID { get; set; } public string CustomerName { get; set; } } public class Order { public int ID { get; set; } public int CustomerID { get; set; } public DateTime OrderDate { get; set; } public Decimal OrderAmount { get; set; } } 

Modelli di presentazione

Un modello di presentazione è una class di utilità che viene utilizzata per eseguire il rendering di dati su uno schermo o un report. I modelli di presentazione vengono in genere utilizzati per modellare strutture di dati complesse composte da dati di più DTO. I modelli di presentazione rappresentano spesso una visione denormalizzata dei dati.

Caratteristiche dei modelli di presentazione:

• Sono oggetti business: la loro definizione dipende dai dati dell’applicazione.

• Contiene principalmente proprietà. Il codice è in genere limitato alla formattazione dei dati o alla conversione da o verso un DTO. I modelli di presentazione non dovrebbero contenere la logica aziendale.

• Spesso presente una vista denormalizzata dei dati. Cioè, spesso combinano proprietà da più DTO.

• Spesso contengono proprietà di un tipo di base diverso da un DTO. Ad esempio, gli importi in dollari possono essere rappresentati come stringhe in modo che possano contenere virgole e un simbolo di valuta.

• Spesso definito dal modo in cui vengono utilizzati e dalle loro caratteristiche dell’object. In altre parole, un semplice DTO che viene utilizzato come modello di supporto per il rendering di una griglia è in realtà anche un modello di presentazione nel contesto di tale griglia.

I modelli di presentazione vengono utilizzati “come necessario” e “dove necessario” (mentre i DTO sono in genere legati allo schema del database). Un modello di presentazione può essere utilizzato per modellare i dati per un’intera pagina, una griglia su una pagina o un menu a discesa su una griglia in una pagina. I modelli di presentazione spesso contengono proprietà che sono altri modelli di presentazione. I modelli di presentazione sono spesso costruiti per uno scopo monouso come il rendering di una griglia specifica su una singola pagina.

Un esempio di modello di presentazione:

 public class PresentationOrder { public int OrderID { get; set; } public DateTime OrderDate { get; set; } public string PrettyDate { get { return OrderDate.ToShortDateString(); } } public string CustomerName { get; set; } public Decimal OrderAmount { get; set; } public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } } } 

Visualizza i modelli

Un modello di vista è simile a un modello di presentazione in quanto è una class di supporto per il rendering di una vista. Tuttavia è molto diverso da un modello di presentazione o da un DTO nel modo in cui è costruito. I modelli di vista spesso contengono le stesse proprietà dei modelli di presentazione e degli DTO e per questo motivo vengono spesso confusi l’uno con l’altro.

Caratteristiche dei modelli di vista:

• L’unica fonte di dati utilizzata per il rendering di una pagina o di uno schermo. Di solito questo significa che un modello di visualizzazione esporrà ogni proprietà che qualsiasi controllo sulla pagina dovrà renderizzare correttamente. Rendere la modellazione della vista l’unica fonte di dati per la vista migliora notevolmente la sua capacità e il valore per il test dell’unità.

• Gli oggetti compositi contengono proprietà costituite da dati dell’applicazione e proprietà utilizzate dal codice dell’applicazione. Questa caratteristica è cruciale quando si progetta il modello di vista per la riusabilità ed è discusso negli esempi seguenti.

• Contiene il codice dell’applicazione. Visualizza I modelli di solito contengono metodi chiamati durante il rendering e quando l’utente interagisce con la pagina. Questo codice si riferisce in genere alla gestione degli eventi, all’animazione, alla visibilità dei controlli, allo stile, ecc.

• Contengono codice che chiama servizi aziendali allo scopo di recuperare dati o inviarli a un server di database. Questo codice viene spesso inserito erroneamente in un controller. La chiamata ai servizi aziendali da un controller di solito limita l’utilità del modello di vista per il test dell’unità. Per essere chiari, visualizzare i modelli stessi non dovrebbe contenere la logica aziendale, ma dovrebbe effettuare chiamate a servizi che contengono la logica aziendale.

• Spesso contengono proprietà che sono altri modelli di visualizzazione per altre pagine o schermate.

• Sono scritte “per pagina” o “per schermata”. Un modello di vista univoco viene in genere scritto per ogni pagina o schermata in un’applicazione.

• Di solito derivano da una class base poiché molte pagine e schermate condividono proprietà comuni.

Visualizza la composizione del modello

Come affermato in precedenza, i modelli di vista sono oggetti compositi in quanto combinano proprietà dell’applicazione e proprietà dei dati business su un singolo object. Esempi di proprietà dell’applicazione comunemente utilizzate che vengono utilizzate sui modelli di visualizzazione sono:

• Proprietà utilizzate per visualizzare lo stato dell’applicazione come messaggi di errore, nome utente, stato, ecc.

• Proprietà utilizzate per formattare, visualizzare, stilizzare o animare i controlli.

• Proprietà utilizzate per l’associazione dati come oggetti elenco e proprietà che contengono dati intermedi immessi dall’utente.

I seguenti esempi mostrano perché la natura composita dei modelli di vista è importante e come possiamo build al meglio un modello di vista efficiente e riutilizzabile.

Supponiamo che stiamo scrivendo un’applicazione web. Uno dei requisiti del design dell’applicazione è che il titolo della pagina, il nome utente e il nome dell’applicazione devono essere visualizzati su ogni pagina. Se vogliamo creare una pagina per visualizzare un object ordine di presentazione, possiamo modificare il modello di presentazione come segue:

 public class PresentationOrder { public string PageTitle { get; set; } public string UserName { get; set; } public string ApplicationName { get; set; } public int OrderID { get; set; } public DateTime OrderDate { get; set; } public string PrettyDate { get { return OrderDate.ToShortDateString(); } } public string CustomerName { get; set; } public Decimal OrderAmount { get; set; } public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } } } 

Questo progetto potrebbe funzionare … ma cosa succede se vogliamo creare una pagina che visualizzerà un elenco di ordini? Le proprietà PageTitle, UserName e ApplicationName verranno ripetute e diventeranno poco maneggevoli con cui lavorare. Inoltre, cosa succede se vogliamo definire qualche logica a livello di pagina nel costruttore della class? Non possiamo più farlo se creiamo un’istanza per ogni ordine che verrà visualizzato.

Composizione sull’eredità

Ecco un modo per ridimensionare il modello di presentazione dell’ordine in modo che diventi un vero modello di visualizzazione e sarà utile per visualizzare un singolo object PresentationOrder o una raccolta di oggetti PresentationOrder:

 public class PresentationOrderVM { // Application properties public string PageTitle { get; set; } public string UserName { get; set; } public string ApplicationName { get; set; } // Business properties public PresentationOrder Order { get; set; } } public class PresentationOrderVM { // Application properties public string PageTitle { get; set; } public string UserName { get; set; } public string ApplicationName { get; set; } // Business properties public List Orders { get; set; } } 

Osservando le due classi precedenti possiamo vedere che un modo per pensare a un modello di vista è che si tratta di un modello di presentazione che contiene un altro modello di presentazione come proprietà. Il modello di presentazione di livello superiore (ad esempio il modello di visualizzazione) contiene proprietà pertinenti alla pagina o all’applicazione mentre il modello di presentazione (proprietà) contiene proprietà rilevanti per i dati dell’applicazione.

Possiamo portare il nostro design un ulteriore passo avanti e creare una class di modelli di visualizzazione di base che possa essere utilizzata non solo per PresentationOrders, ma anche per qualsiasi altra class:

 public class BaseViewModel { // Application properties public string PageTitle { get; set; } public string UserName { get; set; } public string ApplicationName { get; set; } } 

Ora possiamo semplificare il nostro PresentationOrderVM in questo modo:

 public class PresentationOrderVM : BaseViewModel { // Business properties public PresentationOrder Order { get; set; } } public class PresentationOrderVM : BaseViewModel { // Business properties public List Orders { get; set; } } 

Possiamo rendere il nostro BaseViewModel ancora più riutilizzabile rendendolo generico:

 public class BaseViewModel { // Application properties public string PageTitle { get; set; } public string UserName { get; set; } public string ApplicationName { get; set; } // Business property public T BusinessObject { get; set; } } 

Ora le nostre implementazioni sono semplici:

 public class PresentationOrderVM : BaseViewModel { // done! } public class PresentationOrderVM : BaseViewModel> { // done! } 

Se si dispone di proprietà specifiche per la vista e non correlate all’archivio DB / Servizio / Dati, è consigliabile utilizzare ViewModels. Supponiamo di voler lasciare una casella di controllo selezionata in base a un campo DB (o due), ma il campo DB stesso non è un booleano. Sebbene sia ansible creare queste proprietà nel Modello stesso e tenerlo nascosto dall’associazione ai dati, è ansible non voler ingombrare il Modello a seconda della quantità di tali campi e transazioni.

Se i dati e / o le trasformazioni specifici della vista sono troppo pochi, è ansible utilizzare il Modello stesso

Non ho letto tutti i post, ma a ogni risposta sembra mancare un concetto che mi ha davvero aiutato a “farcela” …

Se un modello è simile a una tabella del database, un ViewModel è simile a una vista del database: una vista tipicamente restituisce piccole quantità di dati da una tabella o complessi insiemi di dati da più tabelle (join).

Mi trovo a utilizzare ViewModels per passare informazioni in una vista / modulo e quindi trasferire tali dati in un modello valido quando il modulo torna al controller – anche molto utile per la memorizzazione degli elenchi (IEnumerable).

MVC non ha un viewmodel: ha un modello, una vista e un controller. Un viewmodel fa parte di MVVM (Model-View-Viewmodel). MVVM è derivato dal modello di presentazione ed è reso popolare in WPF. Dovrebbe esserci anche un modello in MVVM, ma la maggior parte delle persone perde completamente il punto di quel modello e avrà solo una vista e un modello visivo. Il modello in MVC è simile al modello in MVVM.

In MVC il processo è suddiviso in 3 diverse responsabilità:

  • View è responsabile della presentazione dei dati all’utente
  • Un controller è responsabile per il stream della pagina
  • Un modello è responsabile della logica aziendale

MVC non è molto adatto per le applicazioni web. È un modello introdotto da Smalltalk per la creazione di applicazioni desktop. Un ambiente web si comporta in modo completamente diverso. Non ha molto senso copiare un concetto vecchio di 40 anni dallo sviluppo del desktop e incollarlo in un ambiente web. Tuttavia, molte persone pensano che sia ok, perché la loro applicazione compila e restituisce i valori corretti. Questo, secondo me, non è abbastanza per dichiarare una certa scelta di design come ok.

Un esempio di un modello in un’applicazione Web potrebbe essere:

 public class LoginModel { private readonly AuthenticationService authentication; public LoginModel(AuthenticationService authentication) { this.authentication = authentication; } public bool Login() { return authentication.Login(Username, Password); } public string Username { get; set; } public string Password { get; set; } } 

Il controller può usarlo in questo modo:

 public class LoginController { [HttpPost] public ActionResult Login(LoginModel model) { bool success = model.Login(); if (success) { return new RedirectResult("/dashboard"); } else { TempData["message"] = "Invalid username and/or password"; return new RedirectResult("/login"); } } } 

I metodi del controller e i modelli saranno piccoli, facilmente verificabili e al punto.

Il modello di vista a è una class semplice che può contenere più di una proprietà di class. Lo usiamo per ereditare tutte le proprietà richieste, ad es. Ho due classi Student e Subject

 Public class Student { public int Id {get; set;} public string Name {get; set;} } Public class Subject { public int SubjectID {get; set;} public string SubjectName {get; set;} } 

Ora vogliamo visualizzare i record Nome dello studente e Nome del sobject nella vista (in MVC), ma non è ansible aggiungere più di una class come:

  @model ProjectName.Model.Student @model ProjectName.Model.Subject 

il codice sopra genererà un errore …

Ora creiamo una class e possiamo dargli qualsiasi nome, ma questo formato “XyzViewModel” renderà più facile la comprensione. È un concetto di ereditarietà. Ora creiamo una terza class con il seguente nome:

 public class StudentViewModel:Subject { public int ID {get; set;} public string Name {get; set;} } 

Ora usiamo questo ViewModel in View

@model ProjectName.Model.StudentViewModel

Ora siamo in grado di accedere a tutte le proprietà di StudentViewModel e alla class ereditata in Visualizza.

Un sacco di grandi esempi, lasciatemi spiegare in modo chiaro e croccante.

ViewModel = Modello creato per servire la vista.

La vista ASP.NET MVC non può avere più di un modello, quindi se abbiamo bisogno di visualizzare le proprietà di più di un modello nella vista, non è ansible. ViewModel serve a questo scopo.

Visualizza modello è una class del modello che può contenere solo le proprietà richieste per una vista. Può anche contenere proprietà da più di una quadro (tabelle) del database. Come suggerisce il nome, questo modello è creato appositamente per i requisiti di visualizzazione.

Di seguito sono riportati alcuni esempi di modelli di visualizzazione

  • Per elencare i dati da più di entity framework in una pagina di visualizzazione – possiamo creare un modello di View e avere proprietà di tutte le entity framework per le quali vogliamo elencare i dati. Unisciti a quelle entity framework del database e imposta le proprietà del modello View e torna alla visualizzazione per mostrare i dati di entity framework diverse in una forma tabulare
  • Il modello di vista può definire solo campi specifici di una singola quadro che è richiesto per la vista.

ViewModel può anche essere usato per inserire, aggiornare i record in più di una entity framework, tuttavia l’uso principale di ViewModel è quello di visualizzare colonne da più entity framework (modello) in una singola vista.

Il modo di creare ViewModel è lo stesso della creazione del modello, il modo di creare la vista per Viewmodel è lo stesso della creazione della vista per Model.

Ecco un piccolo esempio di dati Elenco usando ViewModel .

Spero che questo sia utile.

ViewModel è workarround che rattoppa la goffaggine concettuale del framework MVC. Rappresenta il 4o strato nell’architettura Model-View-Controller a 3 strati. quando Model (modello di dominio) non è appropriato, troppo grande (più grande di 2-3 campi) per la vista, creiamo ViewModel più piccolo per passarlo alla vista.