Potresti dirmi qual è l'obiettivo del pattern MVVM? Quali sono gli argomenti o le ragioni che posso dare a un team e al proprietario del prodotto per rispettare e sviluppare secondo questo modello?
Vorrei una risposta semplice. Qualcosa in una frase o in una parola. È per
La mia risposta semplicistica è che nel concetto MVC standard, il Modello non sa nulla della Vista. Tuttavia, sulle piattaforme GUI che supportano l'associazione dei dati, la vista deve collegarsi a qualcosa che risponda alle modifiche in ciò che l'utente vede e il modello non può riempire in modo soddisfacente tale ruolo. Data Binding è una buona cosa, ma non facilmente riconciliata con MVC.
ViewModel è specificamente un insieme di strutture dati fornite per l'associazione dei dati, in modo che possa contenere tutti gli elementi di dati richiesti dalla vista e essere aggiornato secondo necessità, senza inquinare il modello. In tal modo agisce come un livello tra la vista e il modello, in cui sia il modello che il ViewModel vengono aggiornati dal controller, spesso tramite codice gestito da eventi.
Non sono convinto che Microsoft l'abbia inventato, ma penso che sia nato nella comunità Microsoft, dal momento che l'associazione dei dati è una parte importante delle architetture Microsoft (in particolare quelle basate su XAML).
Wikipedia è abbastanza buono: link
MVVM è fondamentalmente solo una raffinatezza moderna del pattern MVC, quindi l'obiettivo principale è sempre lo stesso di MVC: fornire una netta separazione tra logica di dominio e logica di presentazione. Questo può essere ridotto alla qualità del codice: aderendo ai concetti di alta coesione e accoppiamento libero , si ha una migliore possibilità di sostenere la produttività nel tempo. La chiara separazione delle preoccupazioni semplifica l'uso e la manutenzione del codice e l'accoppiamento tra i componenti rende più semplice il test e il riutilizzo del codice.
Questa sarebbe la mia argomentazione generale per l'utilizzo di MVVM rispetto al non utilizzo di tali pattern. Se è una buona idea utilizzare MVVM in particolare, ad es. MVC o MVP sono effettivamente soggettivi e dipendono dall'applicazione.
I motivi principali dell'utilizzo di MVVM sono Separation of Concerns (SOC) e Single Responsibility Principle (SRP). Poi hai Flessibilità, Manutenzione e Test.
L'obiettivo di MVVM era applicare quanto sopra su WPF. WPF fornisce "plumbing" per consentire un facile utilizzo di MVVM tramite Data Binding.
Per SOC e SRP leggere: Separazione delle preoccupazioni (Wikipedia) e Principio di responsabilità singola (Wikipedia). Ma la base è: alla logica non interessa che il pulsante sia rosso e situato nell'angolo in alto a sinistra. Ci interessa solo l'interfaccia utente.
La flessibilità in questo caso è la capacità che un ViewModel può fornire a diverse viste, oppure una vista può utilizzare diversi ViewModels, che un ViewModel può utilizzare più di un modello e che un modello può essere utilizzato su ViewModel separati.
La manutenzione è una conseguenza di SOC e SRP. È molto più semplice modificare parti del codice o dell'interfaccia utente senza influire su altre sezioni.
Per i test, ora puoi eseguire test automatici della tua logica senza aprire una finestra. Puoi isolare i test e prendere in giro tutto ciò che è necessario (se non del tutto).
Per il proprietario del prodotto ciò che hai da dire è che diventerà più facile apportare modifiche e affermare (test) che l'applicazione si comporta come previsto.
Agli sviluppatori: renderà la tua vita più facile.
Se non stai utilizzando WPF, consulta MVC (Wikipedia) o MVP (Wikipedia)
Leggi altre domande sui tag c# design-patterns mvvm