Eh sì, come titolo è parecchio strano, ma questo post mi frulla in testa da un pò di tempo e quindi volevo buttare giù delle idee/osservazioni che vengono dal mio attuale impiego di MVVM in una applicazione reale.
Il problema ricorrente, a mio avviso, nell’applicazione di pattern è la difficoltà che il neofita incontra nel “visualizzare” materialmente il pattern. E’ giusto che il pattern sia un’entità astratta, ma spesso può essere d’aiuto trovare delle similitudini che lo avvicinino al nostro vivere quotidiano. Con assoluta certezza, posso affermare che MVVM è “sul mercato” da moltissimo tempo, e lo si può trovare in moltissimi prodotti industriali. Alcuni esempi?
- I telefoni cellulari: alcuni modelli di telefoni cellulari (in passato soprattutto) sbandieravano la possibilità di “cambiare cover”. Se osserviamo questo caso possiamo individuare:
- View: la cover intercambiabile
- ViewModel: il display e la tastiera a membrana
- Model: la circuiteria integrata che fa funzionare effettivamente il telefono
La cosa interessante di questo caso è che se tolgo la cover, posso ancora usare il telefono (non è agevole come prima ma si può fare), proprio come succede con i test automatici. Inoltre, la circuiteria non sa nulla della cover, e potrebbe essere impiegata in altro modo, mentre la tastiera a membrana e il display sanno esattamente cosa visualizzare, e come azionare (Command) le funzioni del telefono. Tralasciamo l’analisi della batteria, che potrebbe essere vista come un servizio dalla circuiteria…
- Le automobili: in alcuni casi, le automobili vengono prodotte negli stessi stabilimenti, basandosi sugli stessi progetti ma impiegano marchi differenti. Un esempio reale è quello di una famosa casa tedesca che produce tra le altre le “macchine del popolo” (a buon intenditor…). In questo caso abbiamo un approccio un pochino più complesso:
- View: Carrozzeria, cruscotto, strumentazione, leva del cambio, rivestimento degli interni. Tutto ciò che il proprietario dell’automobile percepisce.
- ViewModel: tutti gli elementi che servono a trasferire comandi alla macchina in quanto “mezzo di trasporto”, o a visualizzare stati della macchina (centralina elettronica, cavi, ecc) scevri da marchi e/o aspetto esteriore. I View Model possono anche essere compositi, ovvero il cruscotto probabilmente può essere suddiviso in una serie di sotto-viewmodel (Tachimento, contachilometri, ecc) ciascuno responsabile di una parte dei dati trasmessi all’autista.
- Model: il telaio, il motore, la trasmissione ecc. In questo caso si potrebbe obiettare che il motore possa essere un servizio… così come l’impianto elettrico.
La cosa importante è che per questa casa di produzione la differenziazione dell’ ultimo strato del MVVM ha permesso di produrre macchine con diverso target economico, mantenendo in comune la produzione di gran parte degli elementi che compongono il Model ed il ViewModel della macchina stessa. Come a dire che l’apparenza ha la sua importanza :-)
Nel nostro settore, per quanto riguarda le applicazioni client, che sono quelle che il cliente “percepisce” può essere effettivamente raggiunto lo stesso livello di “disaccoppiamento” impiegando MVVM.
Personalmente, credo sia sempre interessante osservare come vengono prodotti industrialmente dei beni, perchè spesso la produzione stessa impiega pattern che noi informatici abbiamo formalizzato, ma che effettivamente fatichiamo ad impiegare.