L'attributo [HandleError] è qualche cosa che è stato aggiunto al framework MVC solo dalla release 3, quindi qualcosa di relativamente nuovo.

Si è sentita infatti l'esigenza di avere gli errori generati in sintonia con il resto del sito, e non la classica e sterile pagina d'errore che, per quanto utile, è decisamente asettica e incute terrore.

Sia chiaro che le informazioni continuano ad esserci tutte quante, solo che, come potete vedere nelle figure sottostanti, cambia l'aspetto propositivo verso l'utente finale.

Per poter usufruire di questa feature tutto quello che si deve fare è semplicemente decorare la classe con il controller di nostro interesse con l'attributo in questione.

[HandleError]
public class ContentController : Controller
{
public ActionResult Index()
{....

Assodata dell'importanza del Controller, non si può iniziare ad approfondire quanto di materia ASP.Net Mvc con questa classe. Tutti i file con le varie classi contenenti i Controller vanno necessariemente posizionati nella cartella Controllers.

Affermazione questa vera, ma con la sua debita eccezione. Come ho scritto nel primissimo post, infatti, questo nuovo pattern sembra volerci far dimenticare quanto in auge per il modello a layer, quindi assembly separati per ogni elemento costituente la nostra applicazione.
Confortatevi. E' la prima cosa che sono andato a vedere. Si può comunque fare in modo che i vari elementi MVC risiedano ognuno dentro al suo assembly separato.
Certo, questo rompe un pò le regole del gioco, rendendo meno semplice l'approccio ad MVC: tuttavia, dopo uno scambio e-mail avuto con un referente in Microsoft circa la mia idea, c'è anche da dire che questo modo di operare non è propriamente corretto. In effetti nulla vieta, e anzi viene consigliato lasciare tutto quello che riguarda MVC nel suo progetto e trasferire solo la business-logic in assembly esterni, richiamando poi i vari elementi di interesse come si è sempre fatto fino ad oggi. Ci sarà in sostanza un modo differente di concepire il progetto, ma il succo non cambia.

Indipendentemente che vogliate far risiedere tutta la classe controller in un assembly esterno o che ne stiate creando un nuovo nel progetto base, la nostra classe Controller deve avere una referenza all'assembly System.Web.Mvc.

La tipica classe Controller è così composta:

public class TestController : Controller
{
public ActionResult Index()
{
....
return View();
}
}

Una classe quindi che eredita dalla classe base Controller che il sistema si aspetta di trovare all'interno della cartella corretta.

Non ha importanza che la classe si interfacci al database o ritorni il classico Hello World.

Ogni singolo metodo o funzione della classe Controller di tipo ActionResult sarà una specifica azione a disposizione della nostra chiamata. Questo dovrebbe a questo punto rendere più chiaro la route di default e il fatto che l'action di default è impostato su Index, metodo che generalmente fa poco o niente.

Nel caso sopra, giusto per commentare, non farebbe niente, ma si limiterebbe a chiamare la relativa View contenuta nel seguente percorso ~/Views/Test/Index,aspx.

La mancanza del file appena menzionato, porterebbe inevitabilmente a generare un errore al sistema, che pur cercando il file Test/Index.aspx nei percorsi di default non sarebbe in grado di trovarlo.

Questo reindirizzamento è ovviamente controllabile. Il metodo View, infatti, dispone di diversi overloads, uno tra i quali con un parametro in grado di contenere il path virtuale completo di una vista verso la quale dirigere l'output.
Fare uso di questo parametro è ovviamente un rischio, perchè romperebbe le regole della semplicità e anche quelle di un legame gestito internamente dal framework.
Se infatti, un domani io rinomino la view di destinazione, tutto ciò che è stato scritto all'interno delle mie classi in forma esplicita non verrà aggiornato e questo porterà poi a futuri errori di run-time se non passo la mia applicazione ad una fase di test.

Questo è ovviamente il comportamento base della classe Controller. Ogni singolo metodo può comunque scegliere cosa far ritornare, così come di base ogni metodo pubblico della classe controller viene trattato come una possibile action, a meno che il metodo pubblico non venga decorato con l'attributo NonAction.

Technorati tags: mvc, asp.net

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.

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.

Si 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 questo il meccanismo di base del 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

Sono leggermente in ritardo per parlare di questo argomento, ma meglio tardi che mai. In casi come questi poi, dove le preview sono di casa, è forse quasi un obbligo.

Sto parlando di ASP.Net MVC, il pattern di Model-Controller-View, intorno al quale Microsoft sta sviluppando una parte del suo Framework, disponibile per ora come installazione a parte e quindi non incluso nemmeno nel recente SP1 rilasciato per il framework 3.5.

Il modello MVC consente di realizzare un nuovo tipo di applicazioni web ben differente dal WebForm al quale tutti siamo stati abituati fino ad oggi.
Per diral tutta, mi sembra di essere tornato al vecchio ASP classico, quando, non esistendo affatto il concetto di postback, tutto il processo si svolgeva tra il client che mostrava/intercettava l'azione dell'utente e una pagina server side che si preoccupava di elaborare la richiesta.

Certo, MVC è un pochino più complesso di questo, ma in buona sostanza questo è quello che è successo. Una nuova - netta - separazione dei livelli applicativi. File HTML (pagina aspx) che fa il rendering della pagina (il View), una parte di server-side per eseguire i task (Controller), e la famosa stratificazione e separazione dei dati che vivono per conto loro (Model).
Con questo sistema l'implementazione dei modelli di test è estremamente facilita, quindi non esistono più scuse per incorrere in errore a run-time visto che ora si può verificare tutto durante la fase di sviluppo.

Cosa chiedere di più? La possibilità di utilizzare tutte le nuove tecnologie introdotte nel corso degli anni. Presto detto. Si hanno a disposizione LINQ (Santificate quell'uomo che l'ha inventato) e AJAX tanto per citare le due estensioni più comuni.

Quindi semplice si, ma potente pure !!!

Siamo ancora in Preview, e da dicembre ad oggi si sono succedute ben 4 preview dverse, l'ultima di pochi giorni fa che ulteriormente espanso le possibilità di questo framework.

In sostanza ecco cosa cambia:

• WebForm: come dicevo sopra non esiste più il concetto di pagina con il postback. Sparisce il viewstate. Si torna al caro buon vecchio form HTML con gli attributi action e method la cui action viene demandata al controler.
• Controlli Server: chiaramente non esistendo piu' la logica delle WebForm anche i controlli server principali, non vanno usati. Quindi c'è un ritorno alla input type ....
• Pagina .aspx: le pagine in questo modello ereditano da System.Web.Mvc.ViewPage e quindi, come potete immaginare, ora abbiamo a disposizione nuovi metodi e nuove caratteristiche, prime fra i quali due estensionsione per la HttpContext e la HttpHandler.

Ci sono ancora moltissime cose da fare, e così, dopo scarso un giorno di lettura le prime perplessità che mi vengono in mente sono tutte rivolte alla sicurezza. Cosa e come ci difende questo nuovo modello da fenomeni come l'URL spoofing o l'HTML e SQL injection. Sono cose che quanto prima vorrò andare a verificare. E poi, cosa succede a quella logica tier che per anni ci hanno inculcato nella testa? Ad un primo approccio con un progetto vuoto, sembra tutto essere davvero tornato al modello ASP. Un sacco di fiile con l'aggiunta di un unico assembly.

Spero di potermici dedicare a sufficienza su questo nuovo e promettente aspetto del framework, quindi anche per mia futura memoria, ecco alcune risorse dalle quali iniziare:

• ASP.net learning center, della Microsoft, dove si trovano interessanti webcast sulle loro diverse tecnlogie, MVC incluso ad opera di Scott Hanselman
• Il blog di Stephen Walter o quello di Derik Whittaker
• La reference guide di MVC;
• Vari blog su diversi personaggi Microsoft, tra i quali Scott Guthrie.

Nel mio piccolo cercherò di contribuire anche io scrivendo man mano che affronto gli argomenti.

Technorati tags: MVC