3 pagine in totale: <<Indietro 1 2 [3]
Utilizzare URL personalizzati
Se non si vuole utilizzare questa naming convention resta possibile personalizzare la sequenza con quella più adatta alle proprie esigenze.
Questa funzionalità è implementata attraverso una tabella di routing che può essere personalizzata in qualsiasi momento, andando ad aggiungere le nostre regole di mapping alla collection Routes, esposta come proprietà dalla classe statica System.Web.Mvc.RouteTable.
Questa azione va eseguita all'interno dell'evento Application_Start del Global.asax, come mostrato dallo snippet seguente:
protected void Application_Start()
{
RouteTable.Routes.Add(new Route
{
Url = "[Controller] /[id]/[Action]",
Default= new {action="Index",id=(string)null},
RouteHandler = typeOf(MvcRouteHandler)
});
}
Le funzionalità del Model
Il Model è quella classe che si occupa della persistenza e del fetching dei dati dalla sorgente dati.
Queste classi non hanno la necessità di ereditare da nessuna classe base, nè di utilizzare un attributo in particolare per poter essere utilizzate all'interno di una pagina che utilizzi ASP.NET MVC. Se guardiamo l'esempio precedente, sicuramente dovrà esporre i tre metodi richiesti dal Controller.
La cartella Model dovrà dunque contenere le classi sopra descritte, ma nel caso in cui si disponga di strati di accesso ai dati ben distinti, non è necessario creare il Model, poichè si può utlizzare il proprio sistema di persistenza direttamente dal Controller.
La visualizzazione: il View
Durante il rendering di quanto Model e Controller hanno già elaborato entra in gioco il View. Si tratta di un insieme di pagine e classi che dialogano con il Controller per restituire l'output HTML corretto.
Sfruttando il Framework MVC, è utile sottolinearlo, non si andranno a perdere tutte le comodità introdotte da ASP.NET come Master Pages o User Controls, che possono essere utilizzate ancora senza nessun problema, anche se come già detto si perde per certi versi alcune delle funzionalità tipiche delle WebForm.
Per poter continuare ad utilizzare il sistema di Rewrite messo a disposizione da ASP.NE MVC è necessario effettuare una distinzione dei Controller all'interno della directory chiamata View, presente nella root del nostro sito, in modo che ci sia una directory per ogni controller il cui nome corrisponda al nome del Controller stesso. Nel nostro caso, ad esempio, avremo una directory di nome Products che al suo interno conterrà tre pagine ASP.NET, una per le ognuna delle richieste effettuate dal Controller (List.aspx, ListByCategory.aspx e Detail.aspx).
Le pagine per il View non devono ereditare dalla clase System.Web.UI.Page, ma da System.Web.Mvc.ViewPage<T>.
Questa classe espone una serie di metodi e proprietà necessarie per effettuare il rendering dei dati: uno di questi è il ViewData, ossia il dato prelevato dal Model e passato dal Controller tramite il metodo RenderView, da utilizzare quando è necessario effettuare il rendering della pagina.
Dalla pagina si può utilizzare il ViewData per effettuare il bind di un controllo, piuttosto che associarlo direttamente ad una proprietà:
public partial class Detail : ViewPage<Product>
{
public void Page_Load(
{
if(!IsPostBack)
{
ProductName.Text = ViewData.Name;
ProductDescription.Text = ViewData.Description;
ProductPrice.Text = ViewData.Price.ToString();
}
}
}
<asp:repeater runat="server" id="productRepeater">
<ItemTemplate>
<%# Html.ActionLink (Eval("Name"), new { action = "Detail", id= (int)Eval("Id")} ) %>
</ItemTemplate>
</asp:repeater>
La differenza rispetto all'approccio delle WebForm è che la logica non è presente all'interno della pagina, ma in una classe, e di conseguenza è testabile in maniera automatica. Si noti l'utilizzo della classe Html, il cui metodo statico ActionLink deve essere utilizzato per generare gli URL, dati i parametri necessari a comporre lo stesso.
Conclusioni
Inizialmente si può pensare che un'implementazione del genere abbia dei costi di sviluppo troppo alti rispetto a quanto le WebForm consentano di fare, ma in molti ambienti è necessario avere del codice stabile e testato in qualsiasi punto dell'applicazione, User Interface compresa. In tutti questi casi, infatti, è assolutamente necessario avere la garanzia che non ci siano problemi di regressione o legati all'interfaccia, che spesso vengono a galla solo quando l'applicazione va in produzione.
Molto spesso durante il lavoro quotidiano si vedono moltissimi errori di regressione e la maggior parte di questi sono contenuti nel Presentation Layer, errori evitabili se si effettuasse correttamente il test di quest'ultimo.
I vantaggi di un'implementazione di questo tipo, poi, non si limitano al semplice test o astrazione del codice dalla nostra interfaccia, ma possono innescare una serie di possibilità che fanno sì che il nostro Presentation Layer possa avere una serie di funzionalità prima impossibili senza un approccio del genere, come ad esempio la possibilità di utilizzare un Framework come Spring.Net per sviluppare in AOP (Aspect-Oriented Programming), come descritto in questo post.
In estrema sintesi, un'alternativa al pattern MVC è il Model View Presenter (MVP) descritto su questo articolo di MSDN.
Ad ogni modo, MVC risponde ad una serie di esigenze ben precise ed è dunque utile sottolineare, come sempre, che non è la risposta ad esigenze che non esistono o, per essere più precisi, non è la soluzione su cui tutti i progetti devono per forza puntare. D'altra parte il motivo per cui ASP.NET ha avuto ed ha un così grande successo è senza dubbio il modello semplice che mette a disposizione. Con il Framework MVC, insomma, si ha a disposizione un'altra alternativa utile in tutti quei contesti in cui si hanno le necessità di cui si è già discusso.
3 pagine in totale: <<Indietro 1 2 [3]
Contenuti dell'articolo
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
