MVVM - Introduzione
Il modo ben ordinato e forse il più riutilizzabile per organizzare il codice è usare il pattern "MVVM". IlModel, View, ViewModel (MVVM pattern) è tutta una guida su come organizzare e strutturare il codice per scrivere applicazioni mantenibili, 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 il modello e la vista e rende le cose belle.
View - Contiene semplicemente i dati formattati e sostanzialmente delega tutto al Modello.
Presentazione separata
Per evitare i problemi causati dall'inserimento della logica dell'applicazione in code-behind o XAML, è meglio usare una tecnica nota come presentazione separata. Stiamo cercando di evitarlo, dove avremo XAML e code-behind con il minimo richiesto per lavorare direttamente con gli oggetti dell'interfaccia utente. Le classi dell'interfaccia utente contengono anche codice per comportamenti di interazione complessi, logica dell'applicazione e tutto il resto, come mostrato nella figura seguente sul lato sinistro.
Con la presentazione separata, la classe dell'interfaccia utente è molto più semplice. Ovviamente ha l'XAML, ma il codice alla base fa il meno possibile.
La logica dell'applicazione appartiene a una classe separata, spesso denominata modello.
Tuttavia, questa non è l'intera storia. Se ti fermi qui, è probabile che ripeta un errore molto comune che ti porterà lungo il percorso della follia del data binding.
Molti sviluppatori tentano di utilizzare l'associazione dati per connettere elementi in XAML direttamente alle proprietà nel modello.
A volte questo può andare bene, ma spesso non lo è. Il problema è che il modello è interamente interessato a ciò che fa l'applicazione e non a come l'utente interagisce con l'applicazione.
Il modo in cui presenti i dati è spesso leggermente diverso da come sono strutturati internamente.
Inoltre, la maggior parte delle interfacce utente ha uno stato che non appartiene al modello dell'applicazione.
Ad esempio, se la tua interfaccia utente utilizza un drag and drop, qualcosa deve tenere traccia di cose come dove si trova l'elemento trascinato in questo momento, come dovrebbe cambiare il suo aspetto mentre si sposta su possibili obiettivi di rilascio e come potrebbero cambia quando l'elemento viene trascinato su di essi.
Questo tipo di stato può diventare sorprendentemente complesso e deve essere testato a fondo.
In pratica, normalmente si desidera che un'altra classe si trovi tra l'interfaccia utente e il modello. Questo ha due ruoli importanti.
Innanzitutto, adatta il modello dell'applicazione per una particolare visualizzazione dell'interfaccia utente.
In secondo luogo, è dove vive ogni logica di interazione non banale, e con ciò intendo il codice richiesto per far sì che la tua interfaccia utente si comporti nel modo desiderato.