ASP.NET 3.5

Slides su ASP.Net 3.5 SP1 Dynamic Data

Dario Santarelli — Wed, 26 Nov 2008 17:47:07 GMT

Non che io sia un fan di ASP.NET Dynamic Data, tuttavia ho trovato questa presentazione molto utile per chi vuole avvicinarsi a questa tecnologia senza inciampare :D.

Technorati Tag: ASP.NET

[ASP.NET] PageAsyncTask e pagine asincrone

Dario Santarelli — Sat, 08 Nov 2008 15:23:00 GMT

A partire da ASP.NET 2.0, la classe System.Web.UI.Page introduce un metodo non molto conosciuto in grado di facilitare la realizzazione di pagine asincrone: il metodo RegisterAsyncTask. Spesso mi è capitato di vedere implementare chiamate asincrone (es. invocazione di un WebService) in maniera non corretta sfruttando la logica dell' AddOnPreRenderCompleteAsync, quando in realtà molti dei problemi potevano essere gestiti facilmente tramite Task asincroni, che in ASP.NET sono rappresentati dalla classe PageAsyncTask.
Le differenze tra i due approcci non sono moltissime ma significative. Infatti, entrambi richiedono Async="true" nella direttiva @Page (o AsyncMode = true; da codice) e dunque la predisposizione all'esecuzione asincrona della pagina su thread diversi dopo il completamento del PreRender.
Tuttavia, il metodo RegisterAsyncTask introduce i seguenti vantaggi chiave:

In aggiunta ai metodi Begin/End, permette di registrare un metodo per gestire il timeout di una operazione eventualmente troppo lunga. Il timeout è per-page ed è impostabile tramite l'attributo AsyncTimeout della direttiva @Page: <%@ Page Async="true" AsyncTimeout="10" ... %>
Permette di gestire più PageAsyncTask (ovvero più "async points") all'interno di un ciclo di vita di una pagina asincrona. Questi a loro volta possono essere eseguiti sia in modalità sequenziale che in modalità parallela (grazie a questo overload del contruttore di PageAsyncTask). Anche in questo caso, analogamente al pattern MetodAsync/MethodCompleted disponibile per le classi proxy dei WS (dal framework 2.0 in poi), ASP.NET "ritarda" il rendering della pagina finché tutti i task asincroni non sono stati completati.
Permette di passare un oggetto 'state' ai nostri metodi BeginAsync tramite la classe PageAsyncTask.
Permette di mantenere l'impersonation, la culture e l'oggetto HttpContext.Current nei metodi EndAsync e Timeout (cosa non prevista dal metodo EndAsync registrato con l'approccio AddOnPreRenderCompleteAsync)

Mettiamo insieme il tutto e vediamo un esempio di applicazione dei PageAsyncTask.
Vogliamo elaborare dei feed RSS tramite PageAsyncTask diversi all'interno di una nostra pagina asincrona.

public partial class SampleAsyncPage : System.Web.UI.Page
{

protected void Page_Load(object sender, EventArgs e)
{
     List<string> feeds = new List<string>();
     feeds.Add("http://blogs.msdn.com/MainFeed.aspx?Type=AllBlogs");
     feeds.Add("http://blogs.ugidotnet.org/MainFeed.aspx");
     feeds.Add("http://channel9.msdn.com/Feeds/RSS/");

     foreach (string feed in feeds)
     {
       RegisterAsyncTask(new PageAsyncTask(new BeginEventHandler(BeginAsyncOperation), // BeginAsync
                                           new EndEventHandler(EndAsyncOperation), // EndAsync
                                           new EndEventHandler(TimeoutAsyncOperation), // TimeoutAsync
                                           WebRequest.Create(feed), // State
                                           true // I task registrati verranno eseguiti in parallelo
                                          )
                        );
     }
}

IAsyncResult BeginAsyncOperation(object sender, EventArgs e, AsyncCallback callback, object state)
{
    // In rawFeed abbiamo il feed RSS...
    WebRequest webRequest = (WebRequest)state;
    return webRequest.BeginGetResponse(callback, state);
}

void EndAsyncOperation(IAsyncResult ar)
{
    WebRequest webrequest = (WebRequest)ar.AsyncState;
    string rawFeed = null;

    using (WebResponse response = webrequest.EndGetResponse(ar))
    {
      using (StreamReader reader = new StreamReader(response.GetResponseStream())) rawFeed = reader.ReadToEnd();
    }
    // In rawFeed abbiamo il feed RSS...
}

void TimeoutAsyncOperation(IAsyncResult ar)
{
    // Gestione del Timeout per l' AsyncTask
}
}

Per ciascun feed di un nostro elenco registriamo a livello di pagina un PageAsyncTask che in fase di esecuzione si occuperà di reperire lo stream del feed associato (ad esempio grazie alla classe System.Net.WebRequest). Il miglioramento delle prestazioni è garantito anche dal fatto che l'esecuzione asincrona di ciascun Task verrà gestita da ASP.NET possibilmente in parallelo.

Considerazioni:

Se abbiamo bisogno di una pagina asincrona che gestisca un'unica chiamata asincrona, allora gli approcci AddOnPreRenderCompleteAsync e RegisterAsyncTask sono pressoché equivalenti. Ma se le chiamate asincrone sono molte, è decisamente consigliabile sfruttare le facilitazioni introdotte da RegisterAsyncTask.
Il timeout è per-page e non per-call. Non possiamo cioè assegnare timeout diversi a chiamate asincrone diverse!!! Al massimo possiamo eventualmente modificare a runtime la proprietà AsyncTimeout, il che ovviamente non è la stessa cosa :D
In combinazione con async ADO.NET (es. SqlCommand.BeginExecuteReader) ed in generale con le feature asincrone del framework .NET, le pagine ASP.NET asincrone offrono soluzioni molto convenienti per risolvere comuni problemi di I/O legati a scenari che inibiscono la scalabilità.
In generale non è consigliabile/sicuro gestire operazioni asincrone in ASP.NET utilizzando le API System.Threading (es. ThreadPool.QueueUserWorkItem). Il rischio infatti è quello di "rubare" thread alla normale gestione del ThreadPool di ASP.NET, ottenendo effetti che potrebbero risultare addirittura controproducenti.

Technorati Tag: ASP.NET,PageAsyncTask

[ASP.NET 3.5] AJAX History

Dario Santarelli — Thu, 23 Oct 2008 09:12:40 GMT

ASP.NET 3.5 SP1 introduce un enanchement del controllo ScriptManager che permette di gestire degli stati di navigazione all'interno di una pagina AJAX-enabled accedibili mediante i pulsanti standard "Avanti/Indietro" del browser. In due parole: "Ajax History". Questa funzionalità fu inizialmente introdotta nel vecchio "ASP.NET Futures" mediante il controllo History (in passato scrissi anche un post a riguardo).
La questione è tutt'altro che banale: poiché un browser attiva i meccanismi di navigazione in base al cambio dell' URL, in caso di richieste AJAX che non redirigono verso URL diverse, il browser non aggiorna l' history cache, precludendo all'utente il corretto utilizzo dei pulsanti di navigazione per i diversi stati che desidereremmo impostare nella nostre pagine AJAX-enabled.
La gestione dell' AJAX History non è abilitata di default, tuttavia è molto semplice da implementare. L'unico problema è stabilire che tipo di implementazione ha senso in base alla user experience che si vuole ottenere ed in base al comportamento dei controlli AJAX che si trovano nella nostra pagina.
Partiamo da un classico esempio: Database Northwind, visualizzazione di Products in una GridView ed una DropDownList con AutoPostBack="True" che filtra i Products in base alla Category selezionata. Il tutto piazzato dentro un UpdatePanel.

Senza la gestione dell'history, ogni volta che selezioniamo un Item della DropDownList i dati nella GridView vengono sì aggiornati correttamente, ma se volessimo tenere traccia delle nostre selezioni come stati diversi (navigabili tramite i pulsanti standard "Avanti/Indietro" del browser) dovremmo gestire degli history point, che inoltre ci permettono di rendere eventualmente "bookmarkabili" i vari stati memorizzati, proprio come se fossero pagine diverse. Vediamo come:

1. Impostare EnableHistory="true" nello ScriptManager

<asp:ScriptManager ID="scriptManager_Main" runat="server" EnableHistory="true" 
                   EnableSecureHistoryState="true|false" OnNavigate="scriptManager_Main_Navigate">

L'evento OnNavigate viene scatenato quando viene premuto un pulsante di navigazione del browser, mentre la proprietà EnableSecureHistoryState ci permette di cifrare o meno l'URL associata ad ogni HistoryPoint. Di queste cose ne parliamo tra pochissimo.

2. Gestire il salvataggio degli History point
In uno scenario come quello di esempio, quando selezioniamo una categoria nella DropDownList (evento SelectedIndexChanged), decidiamo si salvare un nuovo history point, poichè di fatto rappresenta uno stato "isolabile" in cui si trova la pagina.

// Creazione di un History Point se:
// 1. Il PostBack avviene in modalità PartialRendering
// 2. Non si stanno utilizzando i pulsanti di navigazione del browser
// 3. E' selezionato un valore non blank della DropDownList

protected void ddlProductsCategories_SelectedIndexChanged(object sender, EventArgs e)
{
if (scriptManager_Main.IsInAsyncPostBack && !scriptManager_Main.IsNavigating
&& ddlProductsCategories.SelectedIndex > 0)
{
scriptManager_Main.AddHistoryPoint("category", ddlProductsCategories.SelectedIndex.ToString(), this.Title);
}
}

In questo caso notiamo come l'overload utilizzato del metodo AddHistoryPoint permetta di associare al nuovo HistoryPoint un titolo, che possiamo usare eventualmente come titolo della pagina.

3. Gestire dell'evento Navigate dello ScriptManager
Grazie a questo evento possiamo impostare uno degli stati salvati grazie alla proprietà State dell' HistoryEventArgs, inizializzata automaticamente da ASP.NET grazie al parsing della querystring.

protected void scriptManager_Main_Navigate(object sender, HistoryEventArgs e)
{
string categoryID = e.State["category"];
if (string.IsNullOrEmpty(categoryID)) ddlProductsCategories.SelectedIndex = 0;
else ddlProductsCategories.SelectedIndex = Convert.ToInt32(categoryID);
updatePanel_Products.Update();
}

4. Gestione della proprietà EnableSecureHistoryState dello ScriptManager
Quando un utente memorizza un nuovo HistoryPoint, automaticamente ASP.NET genera un'unica URL manipolando la querystring, che il browser salva opportunamente in modo tale da renderla navigabile:

A questo punto la proprietà EnableSecureHistoryState ci permette di stabilire in via definitiva se l'URL oggetto dell'HistoryPoint possa o meno essere resa leggibile dall'utente, poiché nel primo caso potrebbe generare un problema di security (ricordiamoci che la querystring esporrebbe le informazioni di stato). Per questo motivo, di default la proprietà EnableSecureHistoryState è impostata a true, generando un URL cifrata del tipo:

http://localhost:49526/WebSite1/Default.aspx#&&DwIbkbGQcKwH...

Technorati Tag: AJAX,ASP.NET

Serializzazione JSON con DataContractJsonSerializer

Dario Santarelli — Tue, 23 Sep 2008 00:27:52 GMT

Una delle novità introdotte dal Framework 3.5 nell' ambito dello sviluppo in AJAX è l'introduzione della classe DataContractJsonSerializer, che di fatto sostituisce la classe JavaScriptSerializer (messa a disposizione dalle precedenti AJAX Extensions 1.0 per ASP.NET 2.0) nella serializzazione/deserializzazione di oggetti JSON. Utilizzando tali extensions la serializzazione/deserializzazione in/da una rappresentazione JSON poteva essere ottenuta in maniera molto semplice con un paio di righe di codice:

using System.Web.Script.Serialization;

Customer customer = new Customer() { Name = "Dario Santarelli", Address = "via Pippo 10", Email = "xxx@yyy.zz" };
JavaScriptSerializer javascriptSerializer = new JavaScriptSerializer();
Console.WriteLine(javascriptSerializer.Serialize(customer));

Oggi invece l'introduzione della classe DataContractJsonSerializer rende obsoleto l'utilizzo del JavascriptSerializer, consigliando invece un' implementazione leggermente diversa dalla precedente. Ad esempio:

using System.Runtime.Serialization.Json;

Customer customer = new Customer() { Name = "Dario Santarelli", Address = "via Pippo 10", Email = "xxx@yyy.zz" };
DataContractJsonSerializer serializer = new DataContractJsonSerializer(customer.GetType());
MemoryStream stream = new MemoryStream();
serializer.WriteObject(stream, customer);
string json = Encoding.UTF8.GetString(stream.ToArray());
Console.WriteLine(json);

Qual'è la differenza tra i due scenari? Per rispondere occorre addentrasi maggiormente nella questione.
Analogamente a quanto richiesto per utilizzo della classe JavaScriptSerializer, al fine di serializzare un oggetto in una stringa JSON tramite DataContractJsonSerializer dobbiamo anzitutto marcare la classe corrispondente come serializzabile. Abbiamo quindi due scelte: possiamo decorare la nostra classe Customer con l'attributo Serializable oppure con l'attributo DataContract (specificando ovviamente l'attributo DataMember per le proprietà di interesse).
Riassumendo, potremmo implementare la nostra classe Customer in due modi diversi, ottenendo però risultati di serializzazione diversi in base al tipo di Serializer scelto.

[Serializable]
public class Customer
{
public string Name { get; set; }
public string Address { get; set; }
public string Email { get; set; }
}

Serializzazione JSON tramite DataContractJsonSerializer :

{"<Address>k__BackingField":"via Pippo 10","<Email>k__BackingField":"xxx@yyy.zz",
"<Name>k__BackingField":"Dario Santarelli"}

Serializzazione JSON tramite JavaScriptSerializer:

{"Name":"Dario Santarelli","Address":"via Pippo 10","Email":"xxx@yyy.zz"}

[DataContract]
public class Customer
{
[DataMember(Name="FullName")]
public string Name { get; set; }

[DataMember(Name = "HomeAddress")]
public string Address { get; set; }

[DataMember]
public string Email { get; set; }
}

Serializzazione JSON tramite DataContractJsonSerializer:

{"Email":"xxx@yyy.zz","FullName":"Dario Santarelli","HomeAddress":"via Pippo 10" }

Serializzazione JSON tramite JavaScriptSerializer:

{"Name":"Dario Santarelli","Address":"via Pippo 10","Email":"xxx@yyy.zz"}

Da questo esempio vanno estrapolati due importanti aspetti:

La serializzazione via DataContractJsonSerializer di un oggetto marcato come Serializable restituisce un output JSON in realtà non compatibile con il serializer client-side di ASP.NET AJAX.
L'eventuale aliasing delle proprietà da serializzare tramite l'uso della proprietà Name dell'attributo DataMember si ripercuote nella generazione della corrispondente rappresentazione JSON da parte del DataContractJsonSerializer, a differenza di quanto accade con l'utilizzo del JavaScriptSerializer.

Technorati Tag: AJAX,ASP.NET

[ASP.NET 3.5] GridView e DataPager

Dario Santarelli — Fri, 08 Aug 2008 11:46:57 GMT

Uno dei nuovi controlli che troviamo nel tab "Data" della ToolBox di VS2008 è il DataPager. L'interessante funzionalità che esso introduce riguarda la gestione del paging per tutti i controlli "bindabili" che implementano l'interfaccia IPageableItemContainer. In VS2008 l'unico controllo che risponde di default a tale requisito è il controllo ListView.
Dunque, se da una parte il ListView e il DataPager costituiscono un' accoppiata già precostituita, dall'altra possiamo adoperarci per "adattare" gli altri data controls (come il GridView) affinchè supportino la paginazione tramite il DataPager. Come è facile intuire, ciò può avvenire estendendo opportunamente tali controlli in modo che implementino l'interfaccia IPageableItemContainer.
Domanda: " Il controllo GridView possiede già un meccanismo built-in di paginazione.... Perché dovrei aver bisogno del DataPager? "
In effetti, il DataPager non introduce qualcosa che prima non si riusciva a fare se non con molto sforzo... tuttavia ci rende più produttivi in un bel po' di situazioni!!! Anzitutto, la separazione tra il gestore della paginazione e il controllo che visualizza i dati ci permette di posizionare i due componenti in punti differenti della pagina. Inoltre, per la stessa GridView possiamo prevedere più pagers che assumono il medesimo comportamento indipendentemente da quale utilizziamo per spostarci avanti/indietro nella visualizzazione dei dati. Un'altra comoda feature messa a disposizione dal DataPager riguarda la possibilità di ottenere la paginazione via QueryString (GET) o via PostBack (POST) semplicemente impostando la proprietà QuerysStringField (più DataPager possono quindi essere "sincronizzati" se utilizzano lo stesso parametro della QueryString). Per ultimo, ma non per importanza, il TemplatePagerField ci permette di modificare a nostro piacimento il layout del DataPager.

In generale, estendere un controllo associabile a dati (es. Repeater, DataList, GridView etc.) per permettere l' interfacciamento con il DataPager non è un compito poi così difficile, ma di certo implica la conoscenza dei meccanismi di databind dei controlli ASP.NET in gioco ;).

Per chi volesse approfondire la questione, consiglio la lettura di questi due ottimi articoli che mostrano due possibili implementazioni di una GridView abilitata al supporto del DataPager:

Technorati tags: GridView, DataPager

Perché passare a soluzioni "ASP.NET REST-ful"... IMHO!!!

Dario Santarelli — Mon, 23 Jun 2008 23:38:31 GMT

Sono ormai alcuni anni che mi occupo prevalentemente di sviluppo Web ed integrazione in ambienti distribuiti nell'ambito del B2B e devo dire che nel corso del tempo lo stile architetturale che mi ha convinto di più per riusabilità, scalabilità ed efficienza è REST. In questo blog ne ho parlato una volta soltanto, partendo da alcune riflessioni non troppo entusiaste di altri blogger che evidenziavano GIUSTAMENTE il fatto che REST in realtà ha costituito per molti (me compreso) un 'modus operandi' ancor prima di sapere che si chiamasse così e che fosse collegato da molto tempo ad un vero e proprio "branch ufficioso" dello sviluppo Web.
Rob Conery afferma:

"...the Web itself is the REST poster child. More accurately: REST is a state of mind..."

In effetti REST (ROA nel Web) esiste e "rivaleggia" con SOA da ormai molto tempo (una decina di anni se non di più) e da quanto ho avuto modo di osservare nella mia esperienza di sviluppatore Web, non è mai riuscito a sfondare nel mondo Enterprise in egual modo (almeno a livello di trend) rispetto al diretto concorrente. Non mi azzardo a supporre quale sia la spiegazione commerciale di questa cosa (anche perché attualmente non ho né le competenze né la conoscenza per farlo), tuttavia da quando ho iniziato a pensare REST-ful, secondo me il vero vantaggio che paga concretamente gli sforzi di implementazione ruota intorno a questo semplicissimo concetto:

Uniformare le interfacce è meglio che specializzarle

A differenza dell'approccio dei WS e in generale di SOA - ovvero promuovere appunto la specializzazione delle interfacce nonché i pattern e gli idiomi dei linguaggi di programmazione in un ambiente distribuito -, REST riduce ulteriormente l'accoppiamento funzionale tra client e server spostando il focus architetturale sulle risorse/entità, risolvendo elegantemente una marea di problemi di integrazione.
In merito, due sono principalmente le obiezioni SOA-oriented che spesso sento affermare da colleghi/blogger:

Risorse differenti dovrebbero avere interfacce e metodi specifici affinché riflettano meglio le loro funzionalità
REST è solo una traslazione dei problemi di (dis)accoppiamento funzionale al livello di scambio di messaggi tra client e server

Personalmente non sono molto d'accordo in entrambi i casi anzitutto perché sono convinto che gli effetti della distribuzione delle applicazioni nel Web sollevi nativamente dei problemi che possono essere risolti in maniera flessibile e scalabile solo da soluzioni REST-ful... partendo dalle "semplici" problematiche di performance (caching, latenza etc.), intermediazione (state management) e monitoraggio fino ad arrivare ai punti caldi della questione:

Identificazione delle risorse tramite URI logici (es. http://.../myWebApp/Customers/[CustomerID]) che di fatto costituiscono una sorta di API ad alto livello di astrazione, implicando un netto miglioramento dell'accessibilità/comprensibilità/reperibilità per diverse figure professionali.
La manipolazione delle risorse, che avviene attraverso le stesse rappresentazioni in combinazione con l'uso dei verbi HTTP (GET, POST, PUT etc.) e NON va contro i principi dell'information hiding (una rappresentazione di una risorsa non ne rivela alcun dettaglio implementativo)
I messaggi tra client e server sono auto-descrittivi e il relativo contenuto è rappresentabile mediante un qualunque media types MIME, il che preserva nativamente lo sviluppatore dall'implementazione di codice ad-hoc per gestire specifici tipi di dati WSDL (se non IDL).
Gli hypermedia stessi costituiscono il motore dello stato delle applicazioni: questo approccio stabilisce definitivamente che le transizioni da uno stato ad un altro di una applicazione sono ESPLICITE e si trovano proprio all'interno della rappresentazione di uno stato e non all'interno della logica di metodi specifici di una o più interfacce esposte (transizioni IMPLICITE).
Esempio: Supponiamo di avere la risorsa http://.../myWebApp/Customers/List la quale elenca la lista dei clienti mediante degli HyperLink all'interno di una pagina XHTML, ognuno dei quali punta ad un' altra specifica risorsa del tipo http://.../myWebApp/Customers/[CustomerID]. Ora, uno user agent che cerca le informazioni di uno specifico cliente ha solo il bisogno di seguire tali Hyperlink semplicemente controllando i dati e i metadati della rappresentazione della risorsa richiesta. In questo semplice caso, mantenere lo stato dell'applicazione nel client invece che sul server aumenta di molto la scalabilità.

ASP.NET e REST

Un aspetto su cui riflettere è che dopo tutto questo tempo Microsoft ha deciso di promuovere REST e ROA al 'grande pubblico', in concomitanza con l'uscita di Visual Studio 2008. Nella fattispecie, abbiamo assistito alla realizzazione di un framework ad-hoc per la creazione di applicazioni REST-ful con ADO.NET Data Services (progetto Astoria - prima come Extension e poi come feature inserita nella SP1 beta del Framework 3.5 assieme all' Entity Framework).
Ma il fatto curioso che ho avuto modo di notare nella mia esperienza è che per molti sviluppatori ASP.NET, i principi di REST sono più percepiti nel pattern MVC piuttosto che nel framework ADO.NET Data Services dedicato. Un errore concettuale? Io sinceramente penso di no.
In questo senso infatti sono assolutamente d'accordo con le riflessioni di Dino Esposito in questi due bellissimi post:

le quali mi portano a pensare che la proclamazione definitiva di REST tra gli sviluppatori ASP.NET in fondo è da attribuire ANCHE all'introduzione degli aspetti REST-like del framework MVC. In particolare, ecco alcune frasi che mi sono piaciute molto:

So what's IMHO the main aspect of the MVC framework? It uses a REST-like approach to ASP.NET Web development. It implements each request to the Web server as an HTTP call to something that can be logically described as a "remote service endpoint". .... I see more REST than MVC in this model. And, more importantly, REST is a more appropriate pattern to describe what pages created with the MVC framework actually do.

E non è finita qui: oggi si possono prendere 'pezzi' dell' architettura ASP.NET MVC e fonderli nello sviluppo dei tradizionali Web Form (Classic ASP.NET). Ad esempio, il Routing delle Url (System.Web.Routing) del framework MVC può essere calato nello sviluppo ASP.NET per implementare URL logiche in perfetto REST-style (ecco un esempio).
Mumble Mumble.... Domanda: Classic ASP.NET e ASP.NET MVC Framework possono fondersi nel nome di REST ???
Se così fosse, ci troveremmo di fronte ad una situazione in cui, da un lato lo sviluppo ASP.NET viene fatto tendere verso soluzioni REST-ful by Design e dall'altro si rischia di 'sporcare' le best practice architetturali di REST e ROA magari per 'accomodare' soltanto alcuni aspetti specifici del mondo MVC nel mondo Classic ASP.NET (basato sul Postback model).

Da perenne e incondizionato sostenitore di REST come standard de facto per l'accesso e l'elaborazione delle risorse nel Web, non posso che apprezzare gli sforzi di Microsoft degli ultimi tempi (e ritengo anche che varrebbe la pena investirci seriamente soprattutto nel settore Systems Integration) ma non posso neanche nascondere delle riserve sul grande ritardo che il paradigma ha avuto per quanto riguarda l'integrazione in Visual Studio ed in particolare in ASP.NET.

Technorati tags: REST, Astoria, MVC, ASP.NET

ASP.NET Routing e WebForms tradizionali

Dario Santarelli — Sat, 03 May 2008 13:58:22 GMT

L'ultima release di ASP.NET MVC (Preview 2) fornisce alcune interessanti novità ed opportunità per gli sviluppatori ASP.NET. In particolare mi ha colpito molto la facilità di implementazione di meccanismi di routing che non siano più dipendenti dal framework MVC e che dunque possano essere facilmente integrati in progetti ASP.NET 'tradizionali'. Infatti, attualmente il framework Mvc è stato partizionato in tre assembly: il solito System.Web.Mvc ed i nuovi System.Web.Routing e System.Web.Abstractions.
Da un punto di vista pratico, uno degli usi sicuramente più ovvi delle funzionalità di routing riguarda la possibilità di realizzare qualcosa di alternativo all' Url Rewriting (Routing e Url Rewriting infatti non sono la stessa cosa (*)): tutto ciò di cui abbiamo bisogno è creare anzitutto una classe che implementi l'interfaccia IRouteHandler e quindi registrare nel Global.asax le nuove 'Routes' associate al nostro IRouteHandler. Vediamo un banale esempio di base:

using System.Web.Routing;
using System.Web.Compilation;

public class WebFormRouteHandler : IRouteHandler
{
public string VirtualPath { get; set; }

public WebFormRouteHandler( string virtualPath ) { this.VirtualPath = virtualPath; }

#region IRouteHandler Members

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
       foreach (var value in requestContext.RouteData.Values)
       {
         requestContext.HttpContext.Items[value.Key] = value.Value;
       }

       IHttpHandler page = (IHttpHandler)BuildManager.CreateInstanceFromVirtualPath(this.VirtualPath, typeof(Page));
       return page;
    }

#endregion
}

Notiamo come l'unico metodo (GetHttpHandler) dell'interfaccia IRouteHandler prende in input il RequestContext (che nel mondo MVC viene solitamente acceduto tramite la proprietà ControllerContext del Controller). Al suo interno, ci sono tutte le informazioni di routing estratte dall'URL (proprietà RouteData), che andiamo a 'copiare' nell'HttpContext affinchè siano utilizzabili all'interno delle nostre WebForms.
Inoltre, nell'implementazione osserviamo l'utilizzo della classe statica BuildManager che ci permette di istanziare una nostra Page (che implementa l'interfaccia IHttpHandler) partendo dal path virtuale.
Analogamente a quanto avviene nel framework MVC, le Routes associate al nostro WebFormRouteHandler : IRouteHandler sono registrate nell'evento Application_Start del Global.asax:

using System.Web.Routing;

public class Global : System.Web.HttpApplication
{
public static void RegisterRoutes(RouteCollection routes)
{
    var detailsHandler = new WebFormRouteHandler( "~/Details.aspx" );
    routes.Add(new Route("category/{category}/item/{id}", detailsHandler));
}

protected void Application_Start( object sender, EventArgs e )
{
    RegisterRoutes(RouteTable.Routes);
}

...

}

A questo punto siamo pronti!
Nelle nostre pagine ASPX recuperiamo i parametri contenuti nell'URL tramite la proprietà HttpContext.Items ["<key>"] (che esiste solamente nel ciclo di vita della singola pagina). Ad esempio:

protected void Page_Load( object sender, EventArgs e )
{
string categoryId = Context.Items["category"].ToString();
string ItemId = Context.Items["id"].ToString();
...
}

(*) Il routing non effettua un rewriting dell'URL vero e proprio, bensì costituisce un meccanismo 'bidirezionale' di generazione di URL.

Technorati tags: ASP.NET MVC

LinqDataSource e LINQ to SQL: Select, Insert, Update, Delete

Dario Santarelli — Wed, 30 Jan 2008 01:14:17 GMT

Ci sono diversi dettagli a cui dobbiamo fare attenzione quando utilizziamo il behaviour di default del controllo LinqDataSource per quanto riguarda le classiche operazioni di Select, Insert, Update, Delete verso un model layer basato su un mapping con tabelle di un database. Infatti, se da una parte questo nuovo controllo rende ancora più immediato ed intuitivo l'accesso al modello dei dati, dall'altra rischia di autogenerare statement SQL spesso non accettabili da un punto di vista di performance, o comunque non sufficientemente ottimizzati per i nostri fini. Riporto quindi alcuni "fatti" da tener presente quando si sfruttano i meccanismi di autogenerazione di query SQL tramite LinqDataSource:

(Ovvio) Qualora non specifichiamo esplicitamente la proprietà Select, vengono estratte tutte le proprietà (o Data Columns se vogliamo) del nostro data object corrispondente al TableName specificato (Tabella Customers nell'esempio).

<asp:LinqDataSource ID="MyLinqDataSource" runat="server"
ContextTypeName="MyDataContext" TableName="Customers"
</asp:LinqDataSource>

In pratica, in questi casi lo statement SQL autogenerato interesserà tutti i campi oggetto di un mapping diretto sulla tabella Customers del DB.
La proprietà Select permette di reperire un sottoinsieme di proprietà del nostro data object, il che significa applicare una projection a runtime su un nuovo Anonymous Type 'bindabile' ad un controllo di presentazione dati (es. ListView). Ad esempio,

<asp:LinqDataSource ... Select="new(ID,FirstName,LN as LastName)" TableName="Customers" ... </asp:LinqDataSource>

potrebbe risultare molto più consigliabile dal momento che rispecchia la buona prassi di estrarre dalla nostra sorgente dati solo e soltanto i campi necessari, evitando dunque costi computazionali inutili da parte dello statement SQL autogenerato, che in questo particolare esempio interrogherà soltanto i campi ID,FirstName e LN della tabella Customers oggetto del mapping
La combinazione delle proprietà Select e GroupBy permette di raggruppare ed aggregare dati su una o più colonne, facendoci poi perdere la possibilità di effettuare insert, update e delete sui dati che stiamo visualizzando
Per abilitare la modifica automatica dei dati dobbiamo impostare a true almeno una delle proprietà EnableUpdate/EnableInsert/EnableDelete (di default impostate a false), ma ciò ci vincola a non impostare la proprietà Select (pena Exception). In questo modo però lo statement SQL autogenerato interrogherà tutti i campi della tabella in mapping con il data object (che verranno memorizzati nel ViewState). Ad esempio, nel caso dell'Update di un record, lo statement SQL autogenerato dal nostro LinqDataSource includerà nella clausola SET solo i campi che hanno subito una variazione reale, mentre nella clausola WHERE tutti i confronti sui campi con i valori precedenti alla modifica.
Negli scenari di insert/update/delete automatica dei record dobbiamo aver cura di fornire l'opportuna interfaccia utente che si occupi tra l'altro della visualizzazione dei campi di interesse: ad esempio, in un GridView associato ad un LinqDataSource con EnableUpdate/EnableInsert/EnableDelete = "true" (quindi privo di Select/GroupBy) potremmo impostare AutoGenerateColumns="false" e dichiarare esplicitamente le Column da renderizzare.

Technorati tags: LinqDataSource , Linq

ASP.NET 3.5 Extensions Preview: occhio al designer nelle applicazioni MVC!

Dario Santarelli — Tue, 25 Dec 2007 15:23:58 GMT

Oggi mentre stavo studiando il supporto MVC nell'ultima release delle ASP.NET 3.5 Extensions Preview mi sono subito accorto del fatto che, creando una MVC View Page/Content Page, il template di default non genera automaticamente il file <page>.designer.cs/.vb.
Questo inconveniente si risolve semplicemente facendo tasto destro sul file all'interno del Solution Explorer e selezionando "Convert to Web Application".
Ma guarda tu ;)...

P.S.: e anche se in clamoroso ritardo... TANTI AUGURI DI BUON NATALE E FELICE ANNO NUOVO A TUTTI VOI !!!

Technorati tags: ASP.NET 3.5 , MVC

ASP.NET Futures: il controllo History

Dario Santarelli — Mon, 10 Sep 2007 01:04:28 GMT

Un classico problema delle applicazioni AJAX è mantenere la consistenza della navigazione quando si utilizzano i controlli ("Avanti" e "Indietro") del browser. Chi sviluppa applicazioni Web AJAX-enabled, sicuramente si è accorto di come spesso l'utilizzo del pulsante "Indietro" del browser ad esempio possa provocare una navigazione verso un contenuto o una pagina non desiderata. Il problema è ancor più evidente se vengono generati diversi postback asincroni all'interno della stessa pagina.
Ebbene, se precedentemente dovevamo trovare soluzioni ad hoc più o meno eleganti a questo tipo di anomalia funzionale, ora abbiamo il controllo History, che rende la programmabilità della navigazione logica delle nostre applicazioni AJAX-enabled molto più naturale ed intuitiva.
Questo server control (attualmente nel namespace Microsoft.Web.Preview.UI.Controls) ha infatti lo scopo di permettere la gestione lato server delle informazioni di stato riguardanti la navigazione (chiamate "history point"), che possono dunque essere sfruttate per ricreare il contenuto corretto della pagina ad ogni interazione dell'utente con il browser. E' inoltre degno di nota l'interfacciamento con l' history-stack del browser: ce ne accorgiamo dando una rapida occhiata al javascript che il controllo genera in fase di rendering ;).
Nello specifico, il funzionamento del controllo prevede che l'invio di ciascuna richiesta di navigazione scateni l'evento Navigate, all'interno del quale possiamo controllare sia URL che history points, al fine di rendere semplice la ricostruzione dello stato "cronologicamente" corretto della nostra pagina.
Il suo utilizzo è veramente banale: supponiamo che nel nostro UpdatePanel sia inserito un Button che genera un AsyncPostback, tramite cui possiamo aggiungere un nuovo "history point". Nella nostra pagina basterà inserire il seguente markup:

...
<asp:History runat="server" ID="PageHistory1" OnNavigate="OnNavigateEvent" />
<asp:Button ID="TestButt" runat="server" Text="Aggiungi nuovo HistoryPoint" OnClick="MyButtonClick" />
...

mentre nel codebehind...

public void OnNavigateEvent(object sender, HistoryEventArgs args)
{
    if (args.State["MyState"] != null)
    {
      // viene recuperato lo stato per la corretta ricostruzione
      // del contenuto della pagina
      string pageStateValue = args.State["MyState"].ToString();         
    }
}

public void MyButtonClick(object sender, EventArgs args)
{
  // Aggiunta di un nuovo HistoryPoint...
  PageHistory1.AddHistoryPoint("MyState", "myData....");
}

Notiamo immediatamente come tutto ruoti intorno all'oggetto State (che è di tipo Dictionary<string,object>), in cui possiamo inserire i nostri HistoryPoint organizzandoli eventualmente per categoria (in base alle key che impostiamo nel Dictionary).
Un' ultima ma fondamentale considerazione riguarda la sicurezza: nonostante ogni informazione di stato possa essere codificata e/o criptata, il controllo History (come il ViewState) va considerato come un qualunque controllo sfruttabile per inviare dati 'maliziosi' al server, quindi potenzialmente non sicuro. Insomma, finché possibile, meglio evitare la memorizzazione di dati sensibili nei nostri HistoryPoint!!!

Technorati tags: ASP.NET, Ajax