Il pattern MVVM mi piace perchè:
- è flessibile;
- permette di realizzare anche la parte “di interfaccia” delle nostre applicazioni in modo “predictable”
- si integra alla perfezione con WPF (e Silverlight).
A mio modesto parere, l’unico problema che ha è il suo nome, e per la precisione la parte ViewModel. Infatti quando si cerca di spiegarlo a dei colleghi che non ne hanno sentito parlare, magari durante dei corsi di formazione, si ha sempre un pò di imbarazzo a descrivere cos’è il ViewModel; soprattutto si fa fatica a comprendere che all’interno del ViewModel ci sono anche i comandi, ovvero il ViewModel diventa sì un contenitore di informazioni, ma espone anche dei metodi per interagire con le informazioni stesse o con altre parti di applicazione (basta pensare alla navigazione). Ora come ora, infatti, siamo ancora molto abituati a vedere il Data-Binding come applicabile solo alla parte Data, e non alla parte Command. Anche in questo caso, sarebbe bene non parlare più di DataBinding, bensì di Binding.
In effetti, a mio parere, un nome più intuitivo potrebbe essere Model-View-Interpreter. L’interpreter (ViewModel) effettivamente fa quello che un interprete linguistico fa tra due persone che non parlano la stessa lingua. I comandi sono le interazioni di una parte (view) con l’altra parte (Model); la parte in ascolto ovviamente può “rispondere” esponendo risultati (collections, oggetti) attraverso l’interprete, che si adopererà a fornirli alla parte View tramite il Binding. Si instaura quindi un vero e proprio dialogo tra il view ed il model a colpi di interazione tramite l’interprete.
Il bello di tutto ciò è che, se per un momento mettiamo da parte la view, ovvero la prima persona, e lavoriamo solo con l’interprete, possiamo “collaudare” la sua capacità di “interpretare” correttamente i comandi, ovvero effettuare Test Automatici.
Tra i vantaggi dell’impiego di MVVM (o MVI) possiamo quindi annoverare:
- Un robusto modello di applicazione
- Una netta suddivisione delle responsabilità di ogni parte di applicazione
- Una chiara modellazione di “chi fa che cosa” nell’applicazione
- L’impiego dei meccanismi di binding di WPF (o Silverlight)
- La possibilità di svincolare completamente il design dell’interfaccia (View) dall’effettiva azione dell’interfaccia (ViewModel)
- La testabilità delle azioni dell’interfaccia (ViewModel) in modo completamente indipendente dall’interfaccia (View)