Attenzione: questo articolo si basa sulla CTP di dicembre 2007 di ASP.NET MVC e pertanto è osoleto.
Consula questo articolo per ASP.NET MVC 1.0 release finale.

Nelle applicazioni in generale, sia quelle specifiche per ilweb che per Windows, la parte più difficile da testare è senza dubbio l'interfaccia,ossia il codice che andiamo a scrivere per mostrare a video le informazioniprelevate dai nostri layer di persistenza.

Il pattern Model View Controller, comunementechiamato MVC, ci permette di separare la logica della nostra interfaccia daltipo di applicazione che si sta sviluppando, dandoci così la possibilità dieffettuare il test del codice, cosa praticamente impossibile senza questaseparazione netta tra gli ambiti. E ci consente, tra le altre cose, di lavorarein TDD (TestDriven Development).

Quasi tutte le tecnologie hanno a disposizione almeno untoolkit per agevolare lo sviluppatore ad utilizzare questo pattern e Microsoftha recentemente annunciato, tramite il suo General Manager Scott Guthrie,che verrà rilasciato un pacchetto per l'implementazione del pattern MVC all'internodelle ASP.NET 3.5 Extension, previste per l'anno prossimo in versione finale erilasciate in questi giorni in versioneCTP, su cui si basa questo articolo.

Guardando alle alternative, senza la necessità di aspettarel'uscita di questa extension, un framework di terze parti molto diffuso è senzadubbio Monoraildi CastleProject, a cui si può dare un'occhiata se si necessita di un prodottogià disponibile su cui basare le proprie applicazioni.

Le componenti di MVC

Andiamo ad analizzare i singoli ruoli di questo pattern, cosìda capire meglio come agisce e cambia il modo di sviluppare il nostro PresentationLayer.

Il diagramma che segue fa capire che ciò che implementiamonella nostra interfaccia viene in realtà scomposto in tre layer ben distintiper comportamento e contenuto:

• il Model avrà il compito di contenere i dati davisualizzare e i metodi che ne permettono l'accesso al nostro engine dipersistenza dati;
• il View avrà il compito di visualizzare i dati da mostrarenella nostra User Interface;
• il Controller è il vero cuore, si occupa delle iterazionicon l'utente invocando i metodi prensenti nel Model e cambiano l'output dellanostra interfaccia tramite il View.

Con una separazione del genere si può intuire che il Viewsarà "quasi" privo di codice server-side, dando la possibilità ad un graficonon esperto di ASP.NET di creare l'interfaccia web un po' come avviene con ClassicASP o tecnologie simili. E ad un tool di testare in maniera automatica tutto ilcodice, perchè di fatto non c'è commistione tra le varie parti in cui puòessere scomposta l'interfaccia utente.

Perchè un Framework?

Molti si potrebbero chiedere quale bisogno ci sia diimplementare un Framework per utilizzare un pattern: la risposta nasce da unaserie di funzionalità che facilitano non di poco il lavoro di uno sviluppatoreweb, come lo stesso motore di Url Rewrite (che andremo a vederesuccessivamente), con una serie di classi presenti all'interno del namespace System.Web.Mvc,che mettono a disposizione numerose funzionalità che altrimenti andrebberocreate manualmente.

Proprio per via di questa complessità intrinseca, il modo diapprocciare le applicazioni basate su questo pattern è diametralmente oppostaalla filosofia che sta dietro le Web Form di ASP.NET come le conosciamo oggi,con un insieme di funzionalità che non sono disponibili ed un nuovo modo dipensare e creare le singole pagine.

Generalmente, utilizzando il modello offerto dalle WebForm,siamo abituati a demandare gran parte delle funzionalità ai controlli, in certicasi perdendo il controllo sull'HTML prodotto, sfruttando PostBack e ViewStateper molte funzionalità di base. Viceversa, il modello offerto da MVC ciconsente un controllo nettamente maggiore su quello che deve essere generato,con però il prezzo da pagare della mancanza di PostBack e ViewState, il nonfunzionamento di alcune caratteristiche come, al momento, ASP.NET AJAX ocontrolli di terze parti.