Model, View, ViewModel (pattern MVVM) è tutto quello di guidarti su come organizzare e strutturare il tuo codice per scrivere applicazioni gestibili, testabili ed estensibili.

Model - Contiene semplicemente i dati e non ha nulla a che fare con la logica aziendale.

ViewModel - Agisce come collegamento / connessione tra Model e ViewModel e rende le cose belle.

View - Tiene semplicemente la data formattata e sostanzialmente delega tutto al Modello.

Il vantaggio principale è consentire una vera separazione tra la vista e il modello oltre a raggiungere la separazione e l'efficienza che si ottiene da questa. Ciò che significa in termini reali è che quando il tuo modello deve cambiare, può essere cambiato facilmente senza che la vista ne abbia bisogno e viceversa.

Ci sono tre cose chiave che derivano dall'applicazione di MVVM:

• Maintainability
• Testability
• Extensibility

• Alcune persone pensano che per una semplice interfaccia utente, MVVM possa essere eccessivo.
• Allo stesso modo, nei casi più grandi, può essere difficile progettare ViewModel.
• Il debug sarebbe un po 'difficile quando abbiamo associazioni di dati complesse.

In generale, il modello è il più semplice da capire. È il modello di dati lato client che supporta le visualizzazioni nell'applicazione.

• È composto da oggetti con proprietà e alcune variabili per contenere dati in memoria.

• Alcune di queste proprietà possono fare riferimento ad altri oggetti del modello e creare il grafico degli oggetti che nel suo insieme sono gli oggetti del modello.

• Gli oggetti del modello dovrebbero generare notifiche di modifica delle proprietà che in WPF significa data binding.

• L'ultima responsabilità è la convalida, che è facoltativa, ma è possibile incorporare le informazioni di convalida sugli oggetti del modello utilizzando le funzionalità di convalida dell'associazione dati WPF tramite interfacce come INotifyDataErrorInfo / IDataErrorInfo.

Lo scopo principale e le responsabilità delle visualizzazioni è definire la struttura di ciò che l'utente vede sullo schermo. La struttura contiene parti statiche e dinamiche.

• Le parti statiche sono la gerarchia XAML che definisce i controlli e il layout dei controlli di cui è composta una visualizzazione.

• La parte dinamica è come le animazioni o le modifiche di stato definite come parte della vista.

• L'obiettivo principale di MVVM è che non ci dovrebbe essere alcun codice nella visualizzazione.

• In vista è almeno necessario il costruttore e una chiamata per inizializzare il componente.

• Il codice logico di gestione degli eventi, azione e manipolazione dei dati non dovrebbe essere nel codice sottostante in View.

• Esistono anche altri tipi di codice che devono essere inseriti nel codice dietro qualsiasi codice richiesto per avere un riferimento all'elemento dell'interfaccia utente. È intrinsecamente codice di visualizzazione.

• ViewModel è il punto principale dell'applicazione MVVM. La responsabilità principale di ViewModel è fornire i dati alla vista, in modo che la vista possa inserire quei dati sullo schermo.

• Consente inoltre all'utente di interagire con i dati e modificare i dati.

• L'altra responsabilità chiave di ViewModel è incapsulare la logica di interazione per una vista, ma ciò non significa che tutta la logica dell'applicazione debba andare in ViewModel.

• Dovrebbe essere in grado di gestire la sequenza appropriata delle chiamate per fare in modo che la cosa giusta avvenga in base all'utente o a eventuali modifiche alla vista.

• ViewModel dovrebbe anche gestire qualsiasi logica di navigazione come decidere quando è il momento di passare a una visualizzazione diversa.

Esistono due modi per costruire le visualizzazioni. Puoi usarne uno qualsiasi.

• Visualizza la prima costruzione in XAML
• Visualizza la prima costruzione in Code-behind

Un modo consiste nell'aggiungere semplicemente il tuo ViewModel come elemento nidificato nel setter per la proprietà DataContext come mostrato nel codice seguente.

<UserControl.DataContext> 
   <viewModel:StudentViewModel/> 
</UserControl.DataContext>

Un altro modo è che puoi eseguire la prima costruzione della vista semplicemente costruendo tu stesso il modello di vista nel codice dietro la tua vista impostando la proprietà DataContext lì con l'istanza.

In genere, la proprietà DataContext è impostata nel metodo di visualizzazione del costruttore, ma è anche possibile rinviare la costruzione fino a quando non viene attivato l'evento Load della visualizzazione.

using System.Windows.Controls;

namespace MVVMDemo.Views { 
   /// <summary> 
      /// Interaction logic for StudentView.xaml 
   /// </summary> 
	
   public partial class StudentView : UserControl { 
      public StudentView() { 
         InitializeComponent(); 
         this.DataContext = new MVVMDemo.ViewModel.StudentViewModel(); 
      } 
   } 
}

Il motivo principale per costruire ViewModel in code-behind invece che in XAML è che il costruttore del modello di visualizzazione accetta parametri, ma l'analisi XAML può costruire elementi solo se definito nel costruttore predefinito.

ViewModelLocator fornisce un modo standard, coerente, dichiarativo e vagamente accoppiato per eseguire la prima costruzione della vista che automatizza il processo di collegamento di ViewModel alla vista. Di seguito è riportato il processo di alto livello di ViewModelLocator.

• Individua il tipo di visualizzazione in fase di costruzione.
• Identificare il ViewModel per quel particolare tipo di visualizzazione.
• Costruisci quel ViewModel.
• Impostare Views DataContext su ViewModel.

Il data binding è la caratteristica chiave che differenzia MVVM da altri modelli di separazione dell'interfaccia utente come MVC e MVP.

Le associazioni di dati possono essere OneWay o TwoWay per far scorrere i dati avanti e indietro tra View e ViewModel.

I modelli di dati impliciti possono selezionare automaticamente un modello appropriato dal dizionario delle risorse corrente per un elemento che utilizza l'associazione dati. Lo fanno in base al tipo di oggetto dati di cui viene eseguito il rendering dal data binding. Per prima cosa devi avere qualche elemento che si lega a un oggetto dati.

Ci sono due attori principali, l'invocatore e il ricevitore nel modello di comando.

Invoker

Invoker è un pezzo di codice che può eseguire una logica imperativa. In genere, è un elemento dell'interfaccia utente con cui l'utente interagisce nel contesto di un framework dell'interfaccia utente. Ma potrebbe essere solo un altro pezzo di codice logico da qualche altra parte nell'applicazione.

Receiver

Il ricevitore è la logica destinata all'esecuzione quando l'invocatore viene attivato. Nel contesto di MVVM, il ricevitore è in genere un metodo nel ViewModel che deve essere chiamato.

Tra l'invocatore e il destinatario c'è un livello di ostruzione che non consente a chi invoca e al ricevitore di conoscersi esplicitamente l'uno dell'altro. Questo è tipicamente rappresentato come un'astrazione dell'interfaccia esposta al chiamante e un'implementazione concreta di tale interfaccia è in grado di chiamare il ricevitore.

No, se la porzione di contenuto fornisce solo la struttura per visualizzare qualcosa sullo schermo e non supporta alcun input o manipolazione da parte dell'utente per quel contenuto. Potrebbe non essere necessario un ViewModel separato, ma potrebbe essere solo un blocco XAML che esegue il rendering in base alle proprietà esposte dal ViewModel padre.

Quando l'applicazione inizia ad accettare l'input di dati dagli utenti finali, è necessario considerare la convalida di tale input. Per assicurarti che sia conforme ai tuoi requisiti generali.

È possibile utilizzare i seguenti modi per esprimere la convalida supportati dall'associazione dati WPF:

• Viene impostato il lancio di eccezioni su una proprietà.
• Implementazione dell'interfaccia IDataErrorInfo.
• Implementazione di INotifyDataErrorInfo.
• Usa regole di convalida WPF.

L'inversione del controllo (IoC) e l'inserimento delle dipendenze sono due modelli di progettazione strettamente correlati e il contenitore è fondamentalmente un pezzo di codice dell'infrastruttura che esegue entrambi questi modelli per te. Il modello IoC riguarda la delega della responsabilità per la costruzione e il modello di inserimento delle dipendenze riguarda la fornitura di dipendenze a un oggetto che è già stato costruito.

Un evento è un costrutto di programmazione che reagisce a un cambiamento di stato, notificando gli endpoint che si sono registrati per la notifica. In primo luogo, gli eventi vengono utilizzati per informare un input dell'utente tramite il mouse e la tastiera, ma la loro utilità non è limitata a questo. Ogni volta che viene rilevato un cambiamento di stato, magari quando un oggetto è stato caricato o inizializzato, un evento può essere attivato per avvisare eventuali terze parti interessate.