Introduzione ad ASP.

NET MVC
Cos ASP.NET MVC?
Febbraio 2007. Scott Guthrie Corporate Vice President della Divisione Sviluppo di Microsoft in volo per partecipare ad una conferenza sulla costa est degli Stati Uniti. Per ingannare lattesa decide di abbozzare un prototipo destinato a diventare il nucleo fondante di quello che sar un nuovo framework per lo sviluppo in ambiente web: ASP.NET MVC. Il progetto prende corpo nei mesi seguenti e a Marzo del 2009 la casa di Redmond rilascia la versione 1, seguita lanno successivo dalla 2 e allinizio di questanno dalla versione 3, con la quale il framework raggiunge finalmente una certa maturit e si pone come valida piattaforma di sviluppo web. Dal punto di vista squisitamente pratico, ASP.NET MVC un nuovo tipo di progetto disponibile in Visual Studio (2008 o 2010) per realizzare applicazioni web: MVC non sostituisce quindi Web Forms che continuer ad essere pienamente supportato da Microsoft, come dimostrano anche le novit introdotte con la versione 4 ma si affianca ad esso, fornendo unalternativa in pi agli sviluppatori .NET. ASP.NET MVC identifica infatti un approccio alternativo al disegno dellapplicazione e rappresenta limplementazione Microsoft del pattern architetturale MVC, in particolare della sua declinazione nota come Model2. Per tale motivo ASP.NET MVC presenta ovviamente aspetti in comune con altri framework che implementano lo stesso pattern, in particolare con Castles MonoRail, senza dubbio uno dei framework MVC pi diffusi in ambito .NET. La presenza di unalternativa implica come ovvio la necessit di comprendere le differenze tra i due approcci per poter esercitare con cognizione di causa tale possibilit di scelta nelluniverso ASP.NET. Il fatto che la nuova piattaforma si chiami ASP.NET MVC non infatti una scelta di marketing bens la chiara indicazione che MVC parte integrante di ASP.NET. Non per niente il codice di MVC si trova nel namespace System.Web.Mvc cio dentro System.Web che poi la casa madre di ASP.NET. Far parte di ASP.NET vuol dire ovviamente poter godere di quelle caratteristiche come la Session, la Membership o la Cache cui siamo gi abituati usando Web Forms. Ma vuol dire anche, e questa una peculiarit di MVC, poter personalizzare il comportamento del sistema, sostituendo una qualunque componente di base con una propria o di terze parti, come nel caso del motore di visualizzazione Razor introdotto nella versione 3 della piattaforma che consente di abbandonare la sintassi dei file .aspx e .ascx per il lato presentation.

I pregi di Web Forms

Visto che MVC non levoluzione di Web Forms ma unalternativa a nostra disposizione naturale chiedersi se era necessaria unalternativa. E soprattutto come si pu scegliere tra le due alternative quella pi adatta al nostro progetto? Cerchiamo di capirlo partendo proprio da pregi e difetti del framework che abbiamo usato fino ad ora. La genesi di ASP.NET Web Forms Quando ASP.NET Web Forms venne rilasciato a Gennaio del 2002, il suo obiettivo pi o meno dichiarato era quello di avvicinare la vasta platea di sviluppatori VB al mondo web. Per raggiungere tale obiettivo la piattaforma si proponeva di nascondere dietro una sofisticata astrazione le caratteristiche dei due pilasti della programmazione web: lHTTP con la sua natura intrinsecamente stateless e lHTML la cui conoscenza al tempo non era particolarmente diffusa nella massa dei programmatori abituati agli applicativi desktop o client/server. Si trattava quindi di riproporre lo stesso approccio RAD che aveva fatto il successo di VB: prendo un controllo, lo rilascio su una form, aggancio del codice ai suoi eventi e il gioco fatto. Lidea di replicare la stessa esperienza di sviluppo su una piattaforma con caratteristiche cos diverse stato un vero e proprio cavallo di Troia che ha consentito allo stuolo di programmatori VB in difficolt

nellapproccio con quello che oggi chiamiamo ASP classico di aggredire il mondo delle applicazioni web senza rimanere tagliati fuori dallesplosione di Internet. I pilastri di ASP.NET Web Forms Al posto di HTTP e HTML, quello che si presentava (e si presenta tuttora) ad uno sviluppatore Web Forms era quindi la classica GUI event-driven traslata in ambiente web attraverso unarticolata gerarchia di potenti controlli lato-server. Controlli in grado di tracciare il proprio stato tra due diverse richieste HTTP (grazie al tanto vituperato ViewState), di renderizzarsi automaticamente in formato HTML e di trasformare i POST lato-client in eventi lato-server. Lapproccio alla programmazione web diventava cos simile a quello Windows Forms: si trascinavano controlli sulla pagina, si agganciava il codice agli eventi e ci si dimenticava del fatto che il magico mantenimento dello stato tra due richieste HTTP indipendenti era garantito dallastrazione sottostante. Il fatto poi che la parte visuale della pagina e quella contenente il codice fossero in due file separati (laspx e laspx.cs o vb) dava anche limpressione di aver trovato il santo Graal della separazione tra interfaccia e logica applicativa.

I difetti di Web Forms

Nel corso degli anni e col passare delle versioni ASP.NET Web Forms stato notevolmente migliorato e raffinato. La filosofia per rimasta pi o meno quella iniziale, anche per i limiti intrinseci dellarchitettura, come dimostra anche laggiunta dei componenti AJAX.NET, anchessi progettati per consentire lo sfruttamento della tecnologia AJAX senza addentrarsi nelle specifiche di gestione lato-client e senza quindi la necessit di ricorrere a Javascript o ad XML. In questi anni tuttavia le esigenze della community di sviluppatori si sono evolute, la produttivit garantita dallo strumento RAD resta importante ma non tanto da andare a discapito di alcuni aspetti fondamentali della buona programmazione quali la facilit di manutenzione del codice o la chiarezza del disegno architetturale. ASP.NET Web Forms comincia a mostrare i segni del tempo e sono quattro i principali difetti che affiorano nel suo utilizzo. Illusoria separazione delle responsabilit (Separation of Concern) La separazione delle responsabilit garantita dalla distinzione tra file .aspx e .aspx.cs (o vb) si rivelata presto illusoria visto che non raggiunge il reale obiettivo di separare il livello di business da quello di presentation che rimangono di fatto fusi nella stessa partial class. Questo non vuol dire che non sia possibile applicare la SoC con ASP.NET Web Forms, quanto piuttosto che la sua applicazione responsabilit totale dello sviluppatore visto che la piattaforma non lo spinge ad andare in quella direzione ma piuttosto verso quella opposta di limitarsi a creare rapidamente pagine che ottengano in un modo o nellaltro il risultato richiesto. Controllo limitato sullHTML prodotto Gli stessi server control che sono stati uno dei motivi del successo di ASP.NET Web Forms sono oggi uno dei punti deboli della piattaforma a causa della limitata possibilit di intervenire sul markup HTML prodotto in fase di renderizzazione. Il controllo sullHTML si fatto nel tempo pi pressante sia a causa di requisiti non funzionali quali laccessibilit del sito, luso di CSS, il supporto per browser o dispositivi diversi sia per merito di flessibili librerie lato-client, come jQuery, che hanno semplificato lapproccio con Javascript. Daltra parte pensare di abbandonare i server control equivale a perdere buona parte dei vantaggi della programmazione RAD di ASP.NET Web Forms. Difficolt nellautomatizzare le procedure di test Negli ultimi anni ha inoltre assunto unimportanza crescente la fase di test degli applicativi. Quando cerchiamo di testare il nostro software cerchiamo in definitiva di verificare che ad un certo input corrisponda un certo output. Se riusciamo ad automatizzare tale controllo in genere molto tedioso ci

risparmiamo lunghe ore di noia (e soprattutto ci assicuriamo che il controllo venga effettivamente svolto ogni volta). Testare una Web Form vuol dire verificare lHTTP Response prodotto data una HTTP Request, il che significa non solo riuscire a replicare tutto lambiente di runtime in cui il Web Forms gira ma anche verificare loutput in termini di markup HTML sul quale abbiamo visto il controllo relativo. Testare unapplicazione Web Forms dunque possibile ma non certo agevole. Onerosit del ViewState e del ciclo di vita dellHTTP Request Fin dalla sua introduzione il ViewState stato uno degli aspetti pi criticati dellintero framework. Anche a causa di un erroneo utilizzo dovuto ad una certa ignoranza sul suo funzionamento, il ViewState pu facilmente assumere dimensioni notevoli e questo specie fuori da una intranet pu compromettere seriamente prestazioni e funzionalit dellapplicazione, in particolare nellutilizzo di Ajax che invece per sua natura dovrebbe essere una tecnologia pensata per alleggerire il passaggio di informazioni tra client e server. A questo si aggiunge ovviamente il complesso e oneroso ciclo di vita della richiesta HTTP che deve necessariamente passare per la creazione ex-novo dei vari server control, per lanalisi del ViewState e quindi per il ripristino dello stato della pagina aspx. Limitare i difetti di Web Forms Ovviamente possibile limitare alcune di queste problematiche con delle regole di buona programmazione. Ad esempio usando un design pattern come MVP per aumentare la SoC del progetto e quindi la sua testabilit. Le novit di ASP.NET 4 consentono poi di generare un HTML pi aderente agli standard. E inoltre pi comodo disabilitare il ViewState (per mezzo del flag ViewStateMode) usandolo solo per i controlli per cui necessario, o controllare il client ID generato dai controlli per facilitarne la manipolazione lato-client con Javascript. Restano per delle problematiche strutturali che suggeriscono lopportunit di pensare un approccio diverso, quello che si realizza con ASP.NET MVC.

Cos MVC?
Per capire cosa sia ASP.NET MVC prima necessario comprendere il funzionamento del design pattern sottostante: MVC. MVC, acronimo di Model-View-Controller, un pattern architetturale, il cui scopo quindi di esprimere schemi di base per impostare l'organizzazione strutturale di un sistema software. Anche se il suo approdo nel mondo .NET abbastanza recente, MVC il realt piuttosto datato visto che la sua prima definizione del 1979 e le prime implementazioni sono in linguaggio Smalltalk. Anche grazie ai comodi strumenti di sviluppo RAD offerti da VB prima e da ASP.NET dopo (o a causa degli stessi, a seconda dei punti di vista), l'applicazione e anche la stessa conoscenza dei design pattern stata fino ad oggi un po' trascurata dagli sviluppatori su piattaforme Microsoft. MVC in definitiva una metodologia che ha come scopo principale quello di separare la modellazione delle informazioni, la presentazione delle stesse e la gestione degli input dellutente in componenti distinte, ciascuna specializzata nel proprio compito. Di ottenere cio quello che in inglese viene chiamato separation of concerns o SoC. In MVC, il Model rappresenta i dati dellapplicazione e le regole di business utilizzate per manipolarli, la View corrisponde agli elementi della UI e il Controller si occupa di gestire la comunicazione tra lutente, che opera per mezzo della UI e il modello. la cosiddetta triade. La definizione originale del pattern era in realt abbastanza vaga ed MVC stato declinato in una serie di differenti variazioni nel corso del tempo. Quella alla base di ASP.NET MVC in particolare molto simile a Model2, una variante ideata da Sun per le sue JSP, che si rivelata particolarmente adatta alla programmazione in ambito web, affidando al Controller una maggiore responsabilit visto che la modalit di interazione dellutente con il sistema via HTTP lo rende il naturale punto di ingresso del flusso di operazioni.

Come funziona Model2?

Nella realizzazione di applicazioni web il pattern MVC va infatti opportunamente declinato per tener conto del fatto che ci troviamo a lavorare a cavallo tra due ambienti: il client, dove si trova lutente tipicamente munito di un browser, e il server dove risiede tutta la logica applicativa.

Il ciclo comincia quando lutente effettua una HTTP Request verso lapplicazione. Generalmente pu trattarsi di una GET (per recuperare informazioni) o di una POST (per modificarle). In ogni caso tale richiesta viene instradata verso il Controller che la interpreta e determina quali siano le azioni da attivare sul Model, cio sui dati gestiti dallapplicazione, in genere determinando un cambio di stato del Model stesso. Il Controller individua quindi la successiva View che deve essere presentata allutente e passa alla stessa il Model modificato. La View responsabile di trasformare i dati del Model in un formato adatto alla presentazione allutente, nel nostro caso di una pagina HTML. A questo punto la Response viene inviata sul client dove il browser la visualizza allutente.

Il panorama MVC sul web

ASP.NET MVC non certo il primo framework per creare applicazioni web basate su MVC. Da questo punto di vista Ruby on Rails senza dubbio il pi popolare. Nato nel 2004 si sviluppa su due fondamentali linee guida: Convention over Configuration (CoC) cio lidea di dare per assodate alcune tecniche dimostratesi funzionali nello sviluppo web utilizzandole come comportamento di base in mancanza di una specifica diversa configurazione e Dont Repeat Yourself (DRY) cio lidea di centralizzare la logica applicativa evitando di ripetere lo stesso codice in pi punti e mantenendo cos il codice pi pulito. Linee guida che caratterizzano anche gli altri framework e lo stesso ASP.NET MVC. Come ad esempio Django, basato sul linguaggio Python, che si caratterizza in particolare per le regole di Routing esprimibili per mezzo di espressioni regolari. Nel mondo Java ci sono diversi framework MVC ma i pi noti direi che sono Spring, Struts e JSF. Pur con delle differenze, tutti e tre implementano il pattern MVC con particolare attenzione alla separazione delle responsabilit. Anche su PHP, in genere considerato linguaggio che favorisce una codifica non proprio rigorosa, disponibile un framework MVC chiamato Zend. Prima della nascita di ASP.NET MVC lopzione pi valida in ambito .NET era senzaltro rappresentata da MonoRail, un framework facente parte del progetto Castle, caratterizzato da una grande flessibilit e facilit di interazione con componenti di terze parti, quali NHibernate per il Model o log4net per il log.

Ciclo di vita di una richiesta in ASP.NET

Abbiamo appurato che ASP.NET MVC unalternativa a Web Forms nella creazione di applicazioni web. Dato che la maggior parte di chi approccia MVC viene da una precedente esperienza Web Forms cerchiamo subito di capire in che modo i due framework si differenziano nellinterazione con lutente, cio in definitiva nella gestione delle richieste HTTP.

Pi o meno tutti conosciamo il ciclo di vita di una Web Form che poi il ciclo di vita di una richiesta HTTP. Ogni richiesta proveniente da un client viene gestita in ASP.NET da un componente dedicato detto HTTP handler, la cui scelta dipende da un algoritmo interno del runtime di ASP.NET. Nel Web Forms tale algoritmo si basa strettamente sulla URL della pagina richiesta, per cui ogni pagina ha un suo HTTP handler che corrisponde pi o meno alla pagina .aspx stessa. In pratica un HTTP handler una classe .NET che implementa linterfaccia IHttpHandler il cui unico metodo ProcessRequest responsabile di interpretare la request e produrre unadeguata response. La System.UI.Page di Web Forms unimplementazione di IHttpHandler molto sofisticata che, nel corso dellesecuzione del metodo ProcessRequest, lancia gli eventi Page_Load, Page_PreRender ma anche Button_Click, cui siamo abituati a rispondere per scrivere il nostro codice. In MVC la scelta dellHTTP handler che debba gestire una particolare richiesta non semplicemente basata sul nome del file richiesto ma affidata ad un modulo ad hoc detto URL routing che si occupa di analizzare la URL della richiesta e determinare quale HTTP handler deve gestirla tra tutti quelli registrati. In MVC in realt tutte le richieste vengono inoltrate ad un unico handler, la classe MvcHandler che funge da punto centrale per lattivazione del Controller scelto sulla base dei parametri che compongono la URL che sar responsabile della gestione della richiesta. Il Controller, nel rispetto del principio SoC ispiratore di MVC, si appoggia a sua volta su una View per la produzione del markup HTML da restituire al client.

Ciclo di vita di una richiesta con ASP.NET MVC

Scendendo ad un livello di dettaglio maggiore possiamo vedere come la caratteristica SoC di MVC si esplicita in un variegato insieme di componenti diverse, ognuna responsabile di una ristretta e ben specifica parte del processo.

Abbiamo gi detto che quando giunge una nuova richiesta HTTP, questa viene presa in carico dal modulo di URL routing. Il modulo confronta la URL associata alla richiesta con linsieme delle Route registrate sullapplicazione e determina quale sia il Ruote handler che deve prenderla in carico. Questo ha il solo compito di determinare il corrispondente HTTP handler (che di base sempre la classe MvcHandler) che a sua volta esamina il dettaglio della richiesta per individuare il Controller a cui farla gestire. Il Controller non viene istanziato direttamente ma per mezzo di una classe di servizio ControllerFactory. compito quindi del Controller, per mezzo di un opportuno componente detto ActionInvoker, determinare quale sia lAction (cio in definitiva il metodo) cui far svolgere le operazioni connesse alla richiesta. Nel passare il controllo allazione il Controller chiede aiuto al Model binder per associare automaticamente i parametri richiesti dal metodo alle informazioni fornite dalla Request. In questa fase entrano in azione anche gli Action filter che consentono di aggiungere in maniera dichiarativa comportamenti aggiuntivi allazione, ad esempio richiedendo una particolare autenticazione, o limitandone lattivazione al metodo GET o POST o ancora impostando il salvataggio in cache dei risultati dellazione. Dopo aver svolto le sue operazioni, coinvolgendo il livello di business logic e quindi il Model, lAction non si occupa direttamente di produrre interfaccia utente ma restituisce invece un Action result che viene analizzato dal Controller per decidere quale View debba essere investita della responsabilit di costruire la Response per lutente. Questa operazione viene svolta per mezzo di un view engine che in grado di interpretare il template rappresentato dalla View, integrarlo con i dati provenienti dal Model e produrre il definitivo risultato. Ad un primo approccio uno schema cos dettagliato pu far pensare ad ASP.NET MVC come un framework tremendamente complesso e difficile dunque da gestire ed utilizzare. In realt non dobbiamo leggere la numerosit di componenti come un problema bens come unopportunit: lopportunit di intervenire in molteplici punti del ciclo di vita per personalizzare il funzionamento della nostra applicazione ad un livello sconosciuto in Web Forms. Sempre ricordando che si tratta di un opportunit e non di un obbligo: per ognuno dei componenti descritti esiste infatti unimplementazione standard, gi fornita con il framework, in grado di coprire la maggior parte della situazioni normali senza alcuna necessit di personalizzarne il comportamento.

I pilastri di ASP.NET MVC

Stante il quadro generale tracciato fino ad ora, dovrebbero essere chiari a tutti i punti di forza di ASP.NET MVC. In primo luogo una separazione delle responsabilit intrinseca nel framework. Ho gi avuto modo di dire che possibile ottenere una SoC anche con Web Forms impegnandosi ad usare regole di buona programmazione, magari con ausilio di pattern quali MVP. Ma si tratta appunto dellimpegno del programmatore che sotto lo stress di una scadenza imminente o di un budget ristretto pu facilmente

vacillare. In MVC la distinzione tra Model, Controller e View induce a rispettare la SoC in maniera pi naturale, pi guidata (o se preferite forzata) da parte della stessa infrastruttura. SoC in MVC vuol dire quindi tanti piccoli componenti (come abbiamo visto studiando il ciclo di vita della request), ognuno con il suo ruolo preciso e definito, piuttosto che la monolitica classe Page. Altro pilastro fondamentale la facilit di testare il codice. Tutti i componenti sono infatti basati su interfacce e sono quindi facilmente mockabili, cio sostituibili nel corso del test con componenti fittizi che restituiscono un risultato prefissato. In questo modo possibile condurre uno unit test su un particolare metodo senza preoccuparsi delle condizioni esterne allo stesso. Il pieno supporto alla Dependency Injection consente di effettuare tale sostituzione in maniera semplice e immediata. A differenza di Web Forms, MVC non richiede che lapplicazione giri nel processo ASP.NET per essere testata, grazie allastrazione del contesto della richiesta HTTP (le classi HttpContext, HttpRequest, ecc.) che vengono incapsulate in classi astratte sganciate dalla pipeline di ASP.NET. Pur essendo integrato in Visual Studio a partire dalla versione Professional (ed essendo quindi per molti la scelta pi naturale), MVC non richiede necessariamente MSTest ma invece compatibile con ogni framework di test in ambiente .NET (NUnit, ecc.). Un altro aspetto che merita di essere considerato, specie da chi in passato ha avuto modo di scontrarsi con una certa rigidit del Web Forms, la capacit di estensione del framework: come ho gi detto tutti i componenti core sono liberamente sostituibili o estendibili con il massimo della flessibilit. Flessibilit che vuol dire poter estendere ma non doverlo fare. Limplementazione di base fornita con MVC infatti in grado di coprire gran parte delle esigenze e lutilizzo della Convention over configuration consente di non dover reinventare ogni volta la ruota potendosi appoggiare su approcci ritenuti convenzionalmente ottimali salvo poter sempre configurare un comportamento diverso e pi adatto alla nostra specifica esigenza. Questi aspetti sono senza dubbio quelli pi qualificanti. Potremmo poi accennare al potente motore di routing che consente di utilizzare URL compatibili con SEO e con REST, o allestremo controllo del markup HTML prodotto che permette di rispettare pi facilmente requisiti non funzionali sullaccessibilit dellapplicazione o sul supporto multi-browser.

WebForms fa per te se
Ora che abbiamo pi chiaro lapproccio di entrambi i framework, torniamo a chiederci quando optare per uno o per laltro. Potremmo continuare a scegliere Web Forms se preferiamo una piattaforma matura e con un ottimo supporto di componenti di terze parti che ci consenta di muoverci sul sicuro. Sicuramente dobbiamo sceglierla se le competenze HTML e Javascript del nostro gruppo di lavoro sono limitate. Grazie ai server control possiamo infatti continuare a limitare il nostro utilizzo di codice lato-client cosa impossibile in MVC. Stessa valutazione nel caso di unapplicazione esistente per la quale sia fondamentale preservare gli investimenti fatti. O ancora nel caso di applicazioni abbastanza semplici da realizzare in tempi rapidi con pochi sviluppi futuri. In questo caso laspetto RAD di Web Forms potrebbe aiutarci mentre limpianto SoC di MVC non avrebbe modo di esprimere le sue migliori qualit nel lungo periodo.

MVC fa per te se
In quali casi la nostra scelta potrebbe cadere invece su ASP.NET MVC? Beh sicuramente se il Test Driven Design e lo Unit Testing sono una nostra priorit vista che larchiettura del framework si sposa perfettamente con queste esigenze. Ma anche se cerchiamo un framework fortemente SoC-oriented che ci aiuti a realizzare unapplicazione facilmente mantenibile e scalabile. O ad esempio se vogliamo il completo controllo del markup della pagina HTML

Magari perch facciamo un notevole utilizzo di librerie Javascript. O perch usiamo molto Ajax e vogliamo farlo in libert e semplicit, senza linfrastruttura del ViewState e delloneroso ciclo di vita della Web Form. O ancora perch abbiamo bisogno di personalizzare il comportamento delle componenti core del framework, potendo agire in un qualunque punto della gestione della richiesta.

In conclusione
ASP.NET MVC un nuovo approccio alla programmazione web, parte integrante di ASP.NET, sviluppato dallo stesso team che lavora su Web Forms a cui si aggiunge come alternativa e non come sostituto. Si sposa perfettamente con TDD anche grazie ad una nativa separazione delle responsabilit e ad una componentistica modulabile ed estensibile facilmente. Rispetto a Web Forms richiede qualche conoscenza in pi del mondo web e dei design pattern, una maggiore consapevolezza di quello che si fa, e questo lo rende un framework alla portata di molti ma non di tutti.