Rilasciato da Microsoft nella sua prima versione nel mese di marzo 2009, ASP.NET MVC rappresenta una valida alternativa al modello WebForms tradizionale. ASP.NET MVC è infatti un framework per lo sviluppo di applicazioni web che combina l'efficacia del modello architetturale Model-View-Controller (MVC appunto), le idee e le tecniche proprie dello sviluppo "agile" (unit testing in primis) e le principali funzionalità di ASP.NET 3.5.

In questo articolo cercheremo di capire le motivazioni che hanno giustificato l'introduzione di ASP.NET MVC, valutandone i punti di forza e le debolezze rispetto al modello classico WebForms. Verranno pertanto evidenziate le differenze esistenti tra le due tecnologie di sviluppo web al fine di saperne riconoscere le situazioni ottimali di impiego.

Capire il pattern MVC

Il pattern architetturale MVC fu introdotto nel corso degli anni ottanta (30 anni fa!) allo scopo di facilitare lo sviluppo di applicazioni composte da numerose interfacce utente, ciascuna caratterizzata da una sua logica di interazione e di trasformazione dei dati trattati. La necessità di gestire la complessità che si accompagnava ad uno sviluppo del tutto destrutturato, caratterizzato per lo più da blocchi monolitici di codice poco specializzato, condusse alla ricerca di un approccio alternativo che garantisse una migliore organizzazione del codice sorgente. Questa ricerca portò alla definizione di MVC.

MVC introduce un certo grado di strutturazione nelle applicazioni, in particolare nello strato di presentazione, individuando tre componenti principali tra loro distinti a cui sono assegnate responsabilità complementari: view, controller e model (vedi figura 1). La view si occupa semplicemente della visualizzazione dell'interfaccia utente. È un componente passivo, particolarmente semplice e privo di logica; per questo motivo non necessita di essere testato dato che il suo output è puramente visuale. Il controller è il componente che ha lo scopo di eseguire le azioni richieste dall'utente e fornire di volta in volta la view per la visualizzazione del risultato. Esso comunica con il model, ovvero con lo strato della business logic. Il controller richiama oggetti e servizi del model senza conoscere gli effetti che verranno prodotti sulla view. Sia il controller che il model presentano la necessità di dover essere testati dal momento che la logica contenuta in essi non è minimale come nel caso della view.

Figura 1 - Model-View-Controller

Il disaccoppiamento esistente tra le parti che abbiamo descritto rappresenta il vero valore aggiunto di questo pattern. Il codice risultante è più robusto, manutenibile e riusabile. La forte separazione delle responsabilità tra i diversi componenti permette di gestire in modo mirato la complessità e di organizzare il codice in modo più efficiente.

Inoltre, sulla base di quanto detto sui componenti di MVC, possiamo considerare la view e il controller come elementi appartenenti a tutti gli effetti allo strato di presentazione. Diversamente, il model può essere visto come un gateway verso la business logic, se non direttamente come la logica di business stessa. In tal senso MVC si integra in modo ottimale con la stratificazione classica delle applicazioni (User Interface, Business Logic Layer e Data Access Layer), dal momento che promuove in modo naturale la Separation of Concerns (SoC), così come del resto fa anche il layering.

La versione del pattern MVC applicata in ASP.NET MVC è nota col nome di "Model 2". Originariamente introdotto con il framework Struts in ambito Java, Model 2 fornisce un meccanismo di invocazione del controller che sfrutta le possibilità offerte dal web e da HTTP. In pratica una richiesta, esplicitata tramite un URL, viene intercettata da un filtro HTTP per essere instradata verso un oggetto in grado di gestirla. In ASP.NET MVC il filtro è il modulo HTTP UrlRoutingModule, che in base alle regole di routing instrada la richiesta verso l'handler HTTP MvcHandler, responsabile di attivare l'oggetto controller di destinazione tramite una classe factory, di eseguire l'azione richiesta e di restituire tramite il view engine l'output visuale renderizzato in base ai dati forniti dal model (vedi figura 2).

Figura 2 - Ciclo di vita di una richiesta in ASP.NET MVC

Tecnologie a confronto

Il ciclo di vita descritto nel paragrafo precedente è profondamente diverso da quello usato nell'ASP.NET tradizionale. Infatti WebForms sfrutta un modello di programmazione basato su eventi, ciascuno dei quali viene usato per attivare ed eseguire codice durante la gestione della richiesta. Il codice inserito nei diversi handler degli eventi è fortemente collegato al contesto in cui viene eseguito e non è isolabile da esso. Questo produce una situazione di accoppiamento che rende praticamente impossibile il ricorso a test automatici per il code-behind delle pagine ASPX.