Lavora con noi

ASP.Net

Siti tematici

Pagine:

RSS

MVVM: Applicare il pattern in progetti Silverlight

di: Andrea Boschin 28 Aprile 2010

Da MVC a MVVM

Il pattern Model-View-Controller porta per la prima volta il paradigma della separazione di compiti, tuttora estremamente importante nel campo della progettazione del software, al livello più vicino all'utente finale ovvero l'interfaccia utente. Fondamentalmente il pattern determina che esistono tre componenti che danno vita all'interfaccia utente:

Componente	Descrizione
Model	la rappresentazione dei dati che dovranno essere presentati all'utente. Questa parte del pattern la possiamo immaginare come una serie di metodi cui la View attinge per visualizzare l'interfaccia (query) e altri metodi usati dal controller per modificare i dati (mutators). Il model è anche in grado di notificare la view che qualcosa è cambiato e provocare l'aggiornamento dell'interfaccia
View	la parte a diretto contatto con l'utente. Pensiamola in termini di finestre, pagine, componenti, etc. Il compito della view è semplicemente di visualizzare le informazioni che provengono dal Model e raccogliere l'interazione dell'utente per inoltrarle al Controller
Controller	si tratta della parte che coordina la View e il Model applicando la logica necessaria. In buona sostanza il controller riceve le azioni effettuate sulla View e compie le dovute operazioni sul Model facendo uso dei metodi di tipo mutator

Una volta digeriti questi concetti, allo scopo di comprendere l'evoluzione verso MVVM, è necessario rendersi conto che in MVC la comunicazione tra View, Controller e Model è fatta semplicemente di chiamate a metodi e/o proprietà, da una parte e/o dall'altra. Ad esempio, se l'utente preme il pulsante "Aggiungi prodotto", la View chiamerà il relativo metodo AddProductClick() sul controller. Quest'ultimo opererà sul Model per completare l'operazione. Al termine il model notifica la View che recupera le modifiche chiamando i metodi o le proprietà necessarie così da visualizzare il prodotto appena aggiunto.

Chi programma in WPF o Silverlight sa bene invece che quando l'applicazione è ben strutturata non vi è alcuna necessità di arrivare a modificare direttamente le componenti della user-interface, quali TextBox, CheckBox, etc. La modifica invece si applicherà direttamente sul dato collegato all'interfaccia utente mediante DataBinding e il runtime si occuperà per noi di aggiornare i controlli che visualizzano questa informazione e viceversa di riportare nelle proprietà i valori modificati dall'utente nel caso contrario.

Potremo quindi dire che, nel caso di Silverlight e WPF, una parte del controller è la fonte dati - il DataContext per intenderci - per la View ed è connesso ad essa esclusivamente per mezzo di DataBinding. La comunicazione sarà perciò sempre tra View e Controller e tra Controller e Model ma in realtà una parte del Model (quello soggetto al databinding) sarà esposto dal Controller.

Quello che abbiamo appena descritto, altro non è che il pattern Model-View-ViewModel che per molti versi è un dialetto del MVC ma che differisce sostanzialmente da esso per il fatto di essere conscio dell'esistenza dei uno strumento come il DataBinding e trarne vantaggio. La differenza quindi è soprattuto nella modalità di accoppiamento tra Controller (qui chiamato ViewModel proprio perchè incapsula una parte del Model) e la View che se in una direzione prende la forma del DataBinding nell'altra si estrinseca nel passaggio di comandi, cioè nell'uso della caratteristica peculiare di WPF che consente il routing di comandi all'interno dell'interfaccia. Ed è proprio questo il punto in cui Silverlight e WPF divergono, perchè il concetto di comando non esiste in Silverlight. Almeno non nativamente.

Pagina successiva

Pagine: