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)
Il meeting è andato… e c’è stata una buona affluenza di pubblico. Ci tenevo molto a ringraziare pubblicamente tutti i presenti, che con le loro domande e curiosità hanno contribuito a rendere il meeting veramente interessante. Per me è stato un onore poter proporre una soluzione che reputo molto interessante. Dai feedback che ho ricevuto alla fine del meeting, molti di voi proveranno .netTiers per vedere se può contribuire a rendere più snello e produttivo il lavoro di tutti i giorni, e questo ha sicuramente dato un senso al lavoro (ed alle nottate) profuse per la preparazione del meeting.
Da parte mia vi ringrazio di cuore ed aggiungo una cosa: ricordate sempre che XeDotNet siete voi, che con la vostra partecipazione ed entusiasmo fate sì che tutto questo sia possibile. Grazie!!