Iniziamo con l’ASP.Net Mvc

Siamo al primo giro di boa, il primo approccio con questo sistema. Dopo aver scaricato la preview di interesse (nel mio caso l’ultima, la 4, disponibile solo su codePlex) ed averla installata, il vostro Visual Studio 2008 conterrà un paio di nuovi template di progetto come mostra l’immagine qui sotto.

new-project-mvc.jpg

Procedendo come di consueto, creando il progetto quindi nella locazione di nostro interesse, e dopo aver acconsentito o meno a creare anche il progetto di Test, ci troveremo dinanzi ad una struttura di questo tipo.
project-structure-mvc.jpgSi notano le tre cartelle del pattern: Models, Views e Controllers, già viste nell’articolo precedente, più una cartella chiamata Contents dove si possono mettere fogli di stile, codice javascript e quant’altro.

Se le prime tre cartelle sono stabdard e insostibuibili, nessuno, invece, ci obbliga a mettere il nostro foglio di stile dentro la cartella Contents.

Del resto quello che farà fede sarà la nostra MasterPage (altra caratteristica comunque presente nel framework MVC, quindi dato un path assoluto per il nostro file dentro al codice della pagina di template, tutte le pagine successive che faranno uso della MasterPage sapranno dove trovare le risorse ad essa associate.

Come funziona il pattern MVC di Microsoft

Alla base di questo sistema, il framework MVC adotta un sistema di routing, cioè di rendirizzamento delle richieste. Avete presente l’URL rewriting con le regular expression?Ecco, in sostanza stiamo parlando di questo.

Si definiscono le route, una, due … n, con un percorso virtuale costituito da paroli chiave che corrispondo ognuna ad una determinata parte del pattern, e queste, indipendentemente dall’URL richiesto dal client in caso di riscontro positivo seguiranno il percorso definito dalla route.

Questo significa che non è più necessario scrivere un sito SEO friendly, perchè di fatto l’ASP.Net MVC è già SEO oriented. Grandioso.Niente più URL Rewriting ne handler per gestire situazioni particolari. Fino ad ogg, infatti, siamo stati obbligati a creare regole di rewriting e implementare handler per gestire il limite della mappatura 1:1 che Asp.Net imponeva, eseguendo e restituendo il codice HTML generato dal file .aspx in
risposta al client richiedente.

Da oggi, con questo pattern, quando un client richiede una pagina al server, IIS non farà più
quella mappatura, ma associa l’URL ad una classe Controller che si preoccupa di richiamare la vista necessaria a generare la
risposta.

Una semplice route nel file global.asax della nostra applicazione web e tutti i mali sono risolti.

In ASP.NET il funzionamento di questo meccanismo di routing può essere
modificato a proprio piacimento. Esiste comunque una regola di default mostrata qui sotto:

routes.MapRoute(

"Default",    // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
);

Come vedete, il comando per definire le routes è estramamente semplice. Si tratta di un metodo con tre paramentri in ingresso che – rispettivamente – indicano il nome, il percorso virtuale e il valore di default. Se quindi il nostro URL chiama una pagina di questo tipo /Products/Album/1, verrà richiamato il metodo Album del ProductsController, passando l’ID 1. Un esempio stupido, ma è il concetto quello che conta.

Si evince quindi un aspetto estramemente importante da quanto detto sin’ora:un legame forte tra Controller e View, che condividono tra di loro il nome della classe del primo con il percorso fisico della secoda e di cui tratterò successivamente.

Technorati tags: mvc

Comments are closed.