3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Come funziona una chiamata ad una pagina basata su ASP.NET MVC
Come avviene per la maggior parte delle applicazioni web, ad ogni URL si ha una corrispondenza su un file fisico esistente sul server. Ad esempio per un URL come http://www.miosito.it/miapagina.asp si ha generalmente un file miapagina.asp all'interno della root.
Adottando il Framework MVC la situazione è un po' diversa: ad ogni richiesta web non si ha una corrispondente richiesta ad un file con lo stesso nome, in quanto la chiamata viene indirizzata ad una nostra classe (il Controller), che penserà a restituire l'output necessario.
Per far ciò il Framework MVC inlude un proprio motore di URL Rewrite interno, che pensa a ridirigere, tramite un HttpHandler, la richiesta all'effettiva funzionalità a cui è associata.
La prima caratteristica che la nostra classe Controller deve rispettare è quella di ereditare da una classe base Controller, presente all'inteno del namespace System.Web.Mvc.
Il seguente diagramma di sequenza mostra il ciclo di vita di una richiesta:
Ovviamente è già disponibile un set di URL di default, senza che si debba specificare esplicitamente ogni singolo indirizzo, anche se si ha la possibilità di personalizzarli qualora sia necessario, intervendo in maniera specifica sul formato da utilizzare.
La struttura di un sito che si basa su ASP.NET MVC
Prima di andare ad analizzare tutte le funzionalità che ci vengono messe a disposizione, è necessario sapere che una volta creata una nuova applicazione di tipo "ASP.NET MVC Web Application", Visual Studio creerà tre cartelle denominate Controllers, Models e Views.
Cosa contengono, come vengono utilizzate e cosa fanno lo andremo a vedere successivamente, per ora ci basti pensare che ci poniamo l'obiettivo di rappresentare a video una vetrina di prodotti in base a queste funzionalità:
- lista categorie;
- lista prodotti per categoria;
- dettaglio prodotto selezionato.
Il Controller
Se le nostre classi hanno una naming convention ben precisa possiamo sfruttare in automatico il motore di rewrite degli URL.
Prendendo come esempio la situazione sopra descritta, ad un URL come www.miosito.it/products viene associata una classe che deve avere come nome ProductsController (ed essere posizionata all'interno della cartella Controllers). Questa classe deve anche ereditare da System.Web.Mvc.Controller ed avrà il compito di analizzare le richieste per i prodotti, per poi invocare il View corretto.
Nel caso si abbia una categorizzazione più fitta dei prodotti, come richiesto nella nostra situazione, non è necessario realizzare un Controller per ogni richiesta, ma si può realizzare lo stesso Controller filtrando l'output in base al tipo di richiesta.
Proviamo a guardare la seguente tabella per inquadrare meglio la problematica:
| Formato URL | Comportamento | Esempio di URL |
|---|---|---|
| /Products/Categories | Mostra tutte le categorie | /Products/Categories |
| /Products/List/Category | Mostra tutti i prodotti di una categoria | /Products/List/NomeCategoria |
| /Products/Detail/ProductID | Mostra il dettaglio di un prodotto | /Products/Detail/69 |
In questo caso specifico, la nostra classe Controller dovrà esporre tre metodi preceduti dall'attributo ControllerAction, come mostrato nello snippet seguente:
public class ProductsController : System.Web.Mvc.Controller
{
[ControllerAction]
public void Categories()
{
IList<Product> products = new ModelDataAccess().GetCategories();
RenderView("List", products);
} [ControllerAction]
public void List(string category)
{
IList<Product> products = new ModelDataAccess().GetByCategory(category);
RenderView("ListByCategory", products);
}
[ControllerAction]
public void Detail(int id)
{
Product detail = new ModelDataAccess().GetByID(id);
RenderView("Detail", detail);
}
}
Lo snippet è pittosto semplice e si può capire perfettamente che il metodo RenderView si occupa di effettuare il rendering dell'output HTML fornito dalla classe View.
Questo metodo accetta due parametri: il primo è il nome del file ASP.NET presente nella View, mentre il secondo è il dato prelevato dal Model necessario alla View per la parte dinamica.
Se si notano le possibili combinazioni degli URL, si può capire che la parte iniziale dell'URL è sempre il nome del Controller (www.miosito.it/Products/), seguito dall'azione (www.miosito.it/Products/List) e finisce, nel caso ci sia, con il dettaglio (www.miosito.it/Product/Detail).
Ovviamente questo non è un caso, ma una necessità per far sì che il sistema automatico di URL Rewrite possa funzionare in maniera automatizzata, senza necessità di intervento da parte dello sviluppatore.
3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Contenuti dell'articolo
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
