Sviluppo Web

Asp Net MVC - Introduzione

Sviluppare applicazioni web oggi è sicuramente più complesso di qualche anno fa, le aspettative sono diverse, l'esperienza utente ormai è il fulcro di tutte le fasi progettuali, in alcuni casi anche più importante dei contenuti stessi. In scenari enterprise poi, dove molto spesso quello web è solo uno dei canali attraverso il quale si usufruisce dei servizi aziendali, una netta separazione tra presentazione dei contenuti e il dominio applicativo che rappresenta tali contenuti è d'obbligo sotto tutti i punti di vista. Ci sono poi scenari in cui l'aderenza agli standard è un requisito ben definito e il controllo completo del codice html generato dalle nostre pagine web assume un'importanza fondamentale: in tutti questi casi Asp.Net MVC può essere la soluzione più adeguata.

 

Che cos’è MVC

Prima di affrontare l’implementazione Microsoft di MVC analizziamo innanzitutto la definizione stessa di Model-View-Controller partendo dalla sua formulazione originaria per arrivare, passando attraverso la storia, all’adattamento web di tale strategia di separazione delle responsabilità.

Il design pattern

MVC, acronimo di Model-View-Controller, è un design pattern pensato per disaccoppiare la logica di dominio, che rappresenta i contenuti, da quella dell’interfaccia che invece li presenta. Questa definizione sottende un insieme di concetti che forse è meglio puntualizzare fin da subito. Innanzitutto che cos’è un pattern? Un pattern non è altro che una soluzione progettuale a un problema ricorrente che può essere espresso da quattro caratteristiche:

-    Il nome, nel nostro caso MVC
-    Il problema che risolve, nel nostro caso il disaccoppiamento della logica di presentazione da quella applicativa.
-    La soluzione al problema, che descrive il modo in cui il pattern risolve il problema affrontato.
-    Eventuali osservazioni, indicazioni e/o effetti collaterali dell’utilizzo della soluzione.

Nella sua formulazione originale, pensata principalmente per applicazioni desktop, l’utente interagisce con l’interfaccia (View) scatenando un’azione gestita da un’entità chiamata Controller, che chiederà al modello di dominio (Model) di aggiornare il proprio stato interno a seguito dell’azione. Una volta aggiornatosi, è il modello stesso a notificare all’interfaccia il cambiamento di stato, scatenando la richiesta da parte della view del nuovo stato interno.


Figura 1 – Il pattern MVC nella sua formulazione originale

Un po’ di storia

Il pattern MVC fu descritto per la prima volta da Trygve Reenskaug, un professore dell’università di Oslo, mentre era in visita con il gruppo di Smalltalk allo Xerox PARC, la più famosa divisione di ricerca della Xerox Corporation con sede a Palo Alto in California, tra l’estate del 1978 e quella del 1979. Smalltalk era un linguaggio di programmazione orientato agli oggetti con una gestione dinamica dei tipi che metteva insieme in modo inseparabile dati e codice, favorendo la scrittura di programmi modellando il mondo reale come oggetti che comunicano tra loro. In questo contesto la separazione delle responsabilità tra oggetti diversi ha reso naturale l’individuazione della strategia che avrebbe preso il nome di MVC, riassunta in un PDF di due paginette datato 10 dicembre 1979, scritto proprio da Trygve Reenskaug, in cui vengono spiegati i ruoli di Model come rappresentazione della conoscenza, View come rappresentazione grafica del model e Controller come collegamento tra utente e sistema. Nel documento viene anche illustrato il ruolo di un quarto attore denominato Editor, uno speciale controller con lo scopo di rendere possibile l’editing delle informazioni visualizzate dalla view.

Model 2

L’interazione diretta tra il modello e l’interfaccia utente rende questa soluzione inadeguata a scenari web, dove è inconsueto che il server contatti il client per notificare l’aggiornamento del proprio stato interno. Proprio per questo in scenari web si preferisce utilizzare un adattamento di questo pattern, chiamato Model 2, in cui è il controller, che in base all’aggiornamento di stato del model seleziona la View successiva da sottoporre all’utente.


Figura 2 – MVC applicato a scenari web: Model 2

Asp.Net MVC

Il 10 dicembre 2007, Microsoft ha rilasciato la prima CTP della sua implementazione di questo pattern che il 13 Marzo del 2009 ha visto la luce con la prima release ufficiale sotto il nome di Asp.Net MVC 1.0. Come in tutte le prime versioni mancava un qualche supporto alla produttività, specie nella realizzazione delle view, fattore a cui gli sviluppatori Asp.Net tengono moltissimo e che ne ha reso l’interesse iniziale non sufficiente a un’adozione anche in quegli scenari dove il nuovo framework poteva fare la differenza. 

Con la seconda versione, rilasciata il 10 marzo 2010, sono stati forniti i principali strumenti di supporto alla renderizzazione delle view e introdotti concetti chiave come le aree, le view tipizzate, gli helper che fanno uso di espressioni lambda, le data annotation e la validazione client-side, portando di fatto il framework alla maturità necessaria alla sua adozione in progetti reali e complessi. 

Con la versione 3.0, rilasciata il 13 gennaio 2011, Microsoft ha introdotto un nuovo view engine, Razor, che va a proporsi come alternativa all’ormai consolidato motore aspx per la realizzazione delle view dinamiche. E’ stato poi arricchito il framework con tutta una serie di classi sui principali punti di estendibilità del core, parallelamente al miglioramento del supporto a Javascript e Ajax. E’ stato inoltre introdotto anche il supporto ai framework di dependency injection, una tecnica che permette di isolare gli strati software eliminando le dipendenze dirette tra di essi.

Durante il MIX 2011, tenutosi a Las Vegas dal 12 al 14 aprile 2011, è stato rilasciato un aggiornamento dei tools per Asp.Net MVC, quindi parliamo di un aggiornamento di Visual Studio 2010 e non del runtime del framework. Con questo update sono stati aggiunti un nuovo template di progetto per le applicazioni intranet, aggiornate le versioni delle librerie javascript dei template e aggiunta la libreria Modernizr per permettere l’utilizzo delle caratteristiche evolute degli standard HTML5 e CSS3 senza rinunciare alla compatibilità dei browser che non le supportano. E’ stato inoltre fornito un nuovo tool per la generazione automatica di classi controller per la gestione delle classiche operazioni CRUD (Create, Read, Update e Delete) a partire dal modello dati esposto da Entity Framework 4.1, anch’esso rilasciato durante il Mix.

Con la versione 4.0, rilasciata insieme a Visual Studio 2012 e .NET 4.5 in RTM il 15 Agosto 2012, vengono introdotte due principali novità: WebApi e il supporto allo sviluppo per dispositivi mobili. La prima permette di realizzare in maniera semplice, senza richiedere la creazione di un progetto WCF, servizi HTTP REST che possano utilizzare sia JSON che XML. La seconda invece fornisce un template che sfrutta jQuery Mobile, HTML 5 e CSS 3 per la creazione di siti web mobile, più una nuova API, chiamata Display Modes, che permette di individuare la tipologia di browser che sta richiedendo una determinata pagina e selezionare un’apposita view sulla base di questa informazione. In questa versione vengono anche aggiunti il supporto alle nuove parole chiave di .NET 4.5 async e await per la realizzazione di controller e action asincroni, e il supporto alle ottimizzazioni per il web mediante i bundle.

Con la versione attuale, la 5.0, il team di Microsoft comincia a enfatizzare l’utilizzo di tutti gli strumenti a disposizione per la realizzazione di applicazione web introducendo il concetto di One Asp.Net. Il template di partenza di un’applicazione web propone adesso la scelta, da un’apposita form, di quali strumenti utilizzare per la propria applicazione tra Web Forms, MVC Web Api, potendoli scegliere anche insieme, se aggiungere o no un progetto di test deselezionato di default, se partire da zero o da un template base e che tipo di autenticazione utilizzare. Il template di base è ora basato su Bootstrap, un framework javascript e css per la realizzazione di applicazioni responsive complete, che semplifica notevolmente lo sviluppo front-end con un approccio basato sulla definizione di griglie logiche potenzialmente diverse a risoluzioni diverse, in modo da adattare il contenuto allo spazio a disposizione. Altra grossa novità è sicuramente Asp.Net Identity, un nuovo approccio alla gestione di autenticazione e protezione per i nostri siti web che sostituisce Memebership API con meccanismi indipendenti da IIS, aprendo verso un approccio allo sviluppo cross-platform che sarà concretizzato con la prossima versione, già annunciata, di asp.net.

MVC Secondo Microsoft

Il framework Asp.Net MVC basa il suo funzionamento sul concetto di convention over configuration, secondo il quale piuttosto che specificare mediante configurazione tutti gli aspetti del funzionamento di un sistema, ad esempio di un framework, si stabiliscono delle convenzioni che vanno bene per la maggior parte degli scenari, rendendo così più semplice la configurazione del funzionamento e la manutenzione degli stessi.

Applicato ad Asp.Net MVC questo significa diverse cose, tra cui avere una ben definita struttura di cartelle e nomenclature dei file che compongono l’applicazione, in modo che sia valida una regola base di individuazione delle risorse necessarie a soddisfare una richiesta. Questa regola non deve necessariamente essere la stessa per tutta l’applicazione o per tutte le aree dell’applicazione, ma può tranquillamente essere, nei limiti del possibile, un parametro a sua volta configurabile. Vediamo meglio di che si tratta analizzando il ciclo di funzionamento di una richiesta.

Ciclo di funzionamento

Ogni richiesta dell’utente è analizzata dal motore di Routing di Asp.Net, che attraverso l’analisi dell’url individua la classe e il metodo che dovrà gestire la richiesta. Per convenzione tale classe avrà il nome indicato nel primo livello dell’url seguito dalla parola “Controller”. Di quest’oggetto, opportunamente istanziato dal runtime, sarà invocato il metodo indicato nel secondo livello dell’url, che nel vocabolario Asp.Net MVC è detto Action Method, seguito eventualmente dai parametri indicati nella parte restante della richiesta. Il metodo invocato gestirà la richiesta e selezionerà la view successiva, che per default sarà una pagina con lo stesso nome del metodo invocato.


Figura 3 – Gestione di una richiesta in Asp.Net MVC

Supponiamo ad esempio che l’utente richieda la pagina http://www.miosito.it/news/dettaglio/12. In questa ipotesi sarà invocato il metodo Dettaglio della classe NewsController passando come parametro l’intero 12. La view restituita per default all’utente si chiamerà proprio Dettaglio.


Figura 4 – esempio di gestione di una richiesta in Asp.Net MVC

Tutto ciò avviene senza aver scritto nessun file XML di configurazione o indicato mediante qualche classe le associazioni tra richiesta dell’utente e componenti che devono gestire tale richiesta.

Conclusioni

In questo primo articolo ci siamo focalizzati su cosa sia MVC e come Microsoft abbia implementato tale pattern. Nei prossimi articoli costruiremo insieme un primo esempio di applicazione Asp.Net MVC, analizzando i vari componenti che ne fanno parte.