Giuseppe Guerrasio : ASP.NET

Yoox dal retail alla piattaforma multibrand per e-commerce

Giuseppe Guerrasio — Mon, 16 Jun 2008 10:30:15 GMT

Una delle attività più interessanti che mi è capitato di seguire negli ultimi mesi è collegata alla revisione architetturale che Yoox Group ha avviato sui suoi servizi e siti Internet.

YOOX Group è il partner globale di Internet retail per i principali brand di moda & design: l’unica azienda di retail su Internet sia multimarca – con la boutique virtuale YOOX.COM, sia monomarca – con i flagship store online sviluppati da YOOX Services.

Nato nel 2000 ha avviato un nuovo modello di business con la boutique virtuale N° 1 al mondo YOOX.COM, che ha contribuito pionieristicamente a creare lo shopping di moda online nel nostro Paese.

L’infrastruttura globale sincronizzata su tre continenti, insieme all’esperienza accumulata in questi anni, hanno portato all’apertura nel 2006 di YOOX Services, società di YOOX Group che progetta e gestisce gli online store per conto dei principali brand di moda & design. YOOX Services realizza i flagship store dei principali brand della moda & design che intendono offrire online la stessa collezione disponibile attualmente nei negozi.

Attualmente i flagship store online monomarca “powered by YOOX” sono: www.marni.com, www.emporioarmani.com, www.diesel.com, www.cpcompany.com, www.stoneisland.com e presto saranno annunciati molti altri virtual store dei principali brand del lusso.

A questi si è aggiunto il nuovissimo THECORNER.COM “powered by YOOX”, un department store online completamente dedicato alle nuove collezioni di designer internazionali ”cutting edge” e a brand italiani di ricerca ognuno con un “corner” dedicato.

Una case history di successo se guardiamo i numeri di YOOX.COM: un sito localizzato in 7 lingue con più di quattro milioni di visitatori al mese e più di un milione di capi consegnati in tutto il mondo nel 2007 in 53 paesi.

Dal punto di vista tecnico la necessità di dover passare da un singolo Internet retailer ad una nuova serie di siti monobrand ha comportato la necessità di una profonda revisione dell’architettura su cui yoox services implementa le soluzioni Internet. I piani di Yoox Group, infatti, prevedono lo sviluppo di un numero significativo di siti monbrand o specialistici e pertanto la nuova piattaforma tecnologica per Yoox Service dovrà prevedere la possibilità di implementare e gestire con sempre maggiore velocità nuove tipologie di siti.

Dal punto di vista architetturale Yoox Services si è trovata di fronte all’esigenza di muovere la propria soluzione per yoox.com da un sito di e-commerce ad una vera e propria piattaforma che possa permettere la costruzione e la gestione di “n” siti, mettendo a fattor comune un insieme di servizi di base con lo scopo di semplificare lo sviluppo , manutenzione e sfruttamento dell’hardware, ma permettendo al tempo stesso il necessario isolamento tra i siti, la flessibilità per gli elementi di interfaccia utente e la costruzione dei contenuti di ciascuno store virtuale, garantendo allo stesso tempo la necessaria scalabilità rispetto al volume di richieste già oggi elevato sul solo Yoox.com.

Per rispondere a queste esigenze Yoox Group ha quindi avviato uno studio per l’implementazione di una nuova piattaforma che viene da identificata con il termine OSS (ONLINE STORE SERVICES) per rispondere alle nuove esigenze del gruppo e garantire gli stessi livelli di qualità , scalabilità e costi offerti dalla soluzione che ha contribuito in modo determinate al successo di Yoox.com.

La nuova architettura è divisa in due componenti fondamentali: una componenti di front-end che si preoccupa di gestire acquisizione di ordini e gestione del sito (catalogo, profili, carrello, pagamenti, etc) ed una componente di back-end che riceve gli ordini attraverso un un meccanismo di code asincrone dove attraverso Microsoft BizTalk e Microsoft Navision vengono gestite le interazioni con i partner , le operazioni logistiche di spedizione e la fatturazione.

La componente di front-end prevede una parte di user interface (UI) , una serie di Web Service per erogazione di servizi a siti terzi (ad esempio il catalogo) ed alle componenti lato client della UI (JS AJAX, FLASH, SILVERLIGHT, WPF\.NET) , una parte di servizi con la logica delle operazioni del sito e uno storage per i dati.

I principi architetturali che guidano il rifacimento della componente di front-end che si è deciso di seguire per l’evoluzione dal mono sito a multi sito possono essere rappresentati come indicato nella seguente figura:

L’idea guida di base è quella di passare da un’architettura single-tenant dove ciascuna istanza dei siti è implementata con una singola soluzione adhoc\custom ,ad una piattaforma che ricalchi la struttura di base dei servizi offerti attualmente in yoox.com, fornendoli con una architettura multi-tenant scalabile e configurabile. I principi architetturali impostati partono dalle idee impostate per le architetture SaaS e quindi gran parte delle impostazioni sulle architetture multi-tenant indicate ottimo documento di Carraro e Chong sull’argomento, ma vengono riadattati alle forti esigenze di flessibilità sugli aspetti di personalizzazione del front-end ed di gestione dei contenuti dello stesso necessari ad una applicazione di questo tipo.

Dal punto di vista tecnologico nell’implementazione della nuova architettura in corso di sviluppo Yoox ha scelto di utilizzare nelle componenti fondamentali la piattaforma Microsoft: Windows Server 2008 con IIS7 come piattaforma Web Server, SQL Server 2008 come storage e .NET 3.5 come framework di sviluppo con Visual Studio Team System e Team Foundation Server per l’implementazione della software factory, Navision e Microsoft BizTalk Server nelle componenti di back-end.

Ulteriore vincolo per la nuova architettura consiste nella necessità di migrare per step successivi anche il sito principale yoox.com e di garantire,quindi, una completa continuità di funzionamento. Proprio per questo motivo la migrazione dalla precedente architettura single-tenant basata su ASP/COM sta procedendo per step che prevedono come prima parte la costruzione dei nuovi servizi e l’aggancio di questi alla attuale interfaccia. Terminata la costruzione dei nuovi servizi, verrà anche migrata la tecnologia utilizzata per la parte di interfaccia utente.

Data la particolarità della natura dei siti, infatti , la profonda necessità di personalizzazione delle componenti di UI è una delle caratteristiche che a spinto Yoox alla decisione di mantenere quest’ultimo aspetto sviluppato ad hoc per ogni tenant. In particolare , oltre alla classica interfaccia HTML sono previste anche interfacce di tipo differente tra cui piccoli smart client residenti sul desktop che offriranno agli utenti la possibilità di un interazione più semplice con il catalogo del sito. Anche le componenti di UI di gestione del sito sono costruite con interfacce smart client.

L’architettura principale del nuovo front-end multi sito di YOOX può quindi essere rappresentata come di seguito:

Le interfacce utente di ciascun tenant\sito accedono ai sevizi forniti dal OSS fornendo sempre un parametro che identifica il tenant stesso e ottenendo in questo modo l’accesso alla logica ed ai dati necessari al funzionamento della specifica istanza. Con questo tipo di approccio, ciascun elemento applicativo può scalare con un approccio orizzontale che comporta la semplice aggiunta di macchine fisiche o virtuali all’architettura su tutti gli strati applicativi , compresa la parte di dati. Anche a questo livello, infatti, viene utilizzato un partizionamento dei dati rispetto alle istanze che identificano i tenant . Questo approccio consente di suddividere i dati in differenti database che possono anche essere ospitati su macchine fisiche o virtuali diverse in funzione delle esigenze di scalabilita. Lo strato di accesso ai dati dei servizi conterrà la logica necessaria ad individuare la partizione corretta in base all’identificativo del tenant\ sito fornito dal chiamante :

Per un chiarimento sul tema del partizionamento dei dati vi rimando ai post fatti in passato sull argomento la scalabilità ed il partizionamento in entità parte 1 e parte 2 . Il disaccoppiamento tra front-end e back-end attraverso l’utilizzo di una coda fa si che il carico prodotto nell’inserimento di ordini o dalla navigazione degli utenti, non si rifletta direttamente sulle componenti che gestiscono le fasi di fatturazione e gestione logistica e di spedizione.

I servizi sono sviluppati con tre differenti interfacce per permettere sia l’interazione con le pagine ASP (COM), sia l’interazione con componenti .NET in process , sia una interfaccia REST con XML o JSON . In questo modo ciascun servizio può o essere direttamente posizionato sulle macchine di front-end per essere consumato da UI HTML o per poter essere eventualmente esposto verso altre applicazioni ad estensione delle potenzialità della piattaforma stessa.

La maggior parte dei servizi utilizza WCF (Windows Communication Foundation) per esporre una parte delle interfacce di accesso e nello strato di accesso ai dati sfruttano le nuove funzionalità offerte da LINQ.

La struttura complessiva del sito può essere quindi rappresentata come di seguito:

Sessioni del lancio online

Giuseppe Guerrasio — Thu, 03 Apr 2008 17:21:32 GMT

Disponibili online le sessioni del lancio. In particolare disponibile anche video e slide della sessione che ho preparato con Mario Fontana e Mauro Minella sul tema Visual Tools For Office da titolo

"Sviluppo di applicazioni per Microsoft Office System"

ADO.NET Data Service

Giuseppe Guerrasio — Tue, 04 Mar 2008 12:00:41 GMT

Un'altra interessante componente disponibile con la CTP delle ASP.NET 3.5 Extension è la nuova infrastruttura per lo sviluppo di Web Data Service ADO.NET Data Service. Si tratta dell'evoluzione in prodotto della tecnologia incubazione denominata "Astoria" mostrata a MIX 07.

Il nuovo framework ha lo scopo di semplificare l'erogazione di sorgenti dati sul Web venendo incontro alla trasformazione che i siti internet stanno avendo nell'utilizzo di queste funzionalità.

I siti Web da semplici erogatori di interfacce HTML si stanno trasformando in erogatori di dati. Con lo sviluppo di AJAX e delle applicazioni RIA si sta passando da un approccio in cui dall'esecuzione del codice lato server si accedeva alle sorgenti dati utilizzate nei siti

ad un approccio in cui dal codice client che si esegue nel browser, si accede direttamente alle sorgenti dati via HTTP, genericamente attraverso un approccio REST

Il framework ADO.NET Data Service è uno strato costruito sopra l'Entity Framework che permette di rendere accessibile attraverso un URL con uno stile REST il modello E/R implementato (per approfondimenti sull'entity framework vi consiglio : http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx e http://msdn2.microsoft.com/en-us/library/cc161164(printer).aspx ). In realtà non permette esclusivamente di esporre modelli dell'Entity framework ma di qualunque entità che implementi l'interfaccia IQueryable <T> .

Oltre a fornire le componenti server per esporre via Http con stile REST il modello di entità, il framework offre due nuove API client per semplificare l'accesso ai dati esposti in questa modalità:

- Un libreria JavaScript che estende i namespace della Microsoft Ajax Library (namespace Sys.Data ed in particolare Sys.Data.DataService nella Script Library MicrosoftAjaxDataService.js)

- una libreria .NET pensata per client sia silverlight che .NET Framework per desktop ( namespace Microsoft.Data.WebClient contenuto nelle Extension con particolare riferimento alle classi WebDataContext e WebDataQuery ).

Per poter analizzare più nel dettaglio il funzionamento del framework partiamo con l'implementare un semplice esempio basandoci sull'Entity Framework. In particolare partiremo con il creare un entity data model sul classico database Northwind per poi esporre con un servizio ADO.NET DataService le entità via http e poi accederci utilizzandole due librerie client citate.

I passi da implementare sono essenzilmente i seguenti:

- Creare il Progetto

- Creare l'Entity Model

- Creare il Data Service e Autorizzare gli accessi

Procediamo con la creazione di un nuovo Web Site. Dopo aver avviato il progetto, includiamo un elemento di tipo ADO.NET Entity Data Model lo connettiamo al classico database Nortwind , ottenendo un nuovo modello che utilizzeremo come base per l'esposizione del servizio di accesso ai dati.

Aggiungiamo ora un elemento di tipo ASP.NET Data Service e lo colleghiamo al modello EDM appena creato

ottenendo un servizio come quello che vediamo di seguito:

Si tratta di un servizio che utilizza WCF ed il nuovo supporto REST offerto da .NET 3.5 e attraverso una infrastruttura costruita sopra queste funzionalità basata sulla classe WebDataService, espone il nostro EDM che in questo caso è basata data context NorthwindEntities che abbiamo appena costruito con il tool dell'entity framework e che stiamo indicando con lo specifico generics previsto dalla classe:

.........

public class Northwind: WebDtataService <NorthwindModel.NorthwindEntities>

........

In realtà la classe WebDataService come abbiamo già detto è in grado di gestire qualunque modello che implementi l'interfaccia IQueryable <T>.

Per autorizzare l'accesso alle informazioni esposte dal servizio utiliziamo la classe di autorizzazione appositamente inserita nel servizio , aggiungendo al configurazione sul costruttore del servizio per ottenere l'accesso ai dati di tutti i clienti contenuti nel database nortwind su cui abbiamo costruito il nostro EDM.

Nel nostro piccolo esempio impostiamo l'accesso completo a tutte le risorse presenti nel modello esposto attraverso il servizio:

namespace SimpleDataService {

public class Northwind : WebDataService<NorthwindEntities> {

public static void InitializeService(IWebDataServiceConfiguration config) {

config.SetResourceContainerAccessRule("*", ResourceContainerRights.All);

}

Per poter effettuare un test sul funzionamento del servizio è possibile inviare direttamente con un browser una richiesta GET del tipo seguente:

http://localhost:2759/WebSite1/Northwind.svc/Customers

con la quale otteniamo accesso ai dati di tutti i clienti. Oppure la seguente con cui otteniamo l'accesso ad uno specifico customer:

http://localhost:2759/WebSite1/Northwind.svc/Customers('alfki')

o ad esempio ai suoi ordini:

http://localhost:2759/WebSite1/Northwind.svc/Customers('alfki')/Orders

Per un introduzione sulla sintassi per ADO.NET DataService potete far riferimento a http://quickstarts.asp.net/3-5-extensions/adonetdataservice/SimpleAddressingSchemeForDataWithUniformURLs.aspx

Utilizzando la specifica sintassi prevista dal servizio si possono effettuare query e modifiche ai dati. In funzione del tipo di content type inviato nell'header http è possibile ottenere risposte con serializzazione XML o JSON.

E' possibile anche implementare dei Query Interceptors o Change Interceptor sul WebService per agganciare del nostro codice e gestire specifiche richieste di Query o modifiche. Ad esempio per intercettare e gestire le richieste di Query sui Customers del nostro esempio si dovrà aggiungere il seguente metodo:

[QueryInterceptor("Customers")]
      public IQueryable<Customers> OnQueryOrders(IQueryable<Customers> customerQuery)
    {
        return from o in customerQuery
               where o.ContactName ==HttpContext.Current.User.Identity.Name
               select o;
    }

che fornirà esclusivamente accesso a quei customer dove il contactname corrisponde al nome dell'utente che sta accedendo al servizio. Per il Change Interceptor si utilizzerà l'attributo [ChangeInterceptor("......")] sul metodo Interceptor.

Oltre agli Interceptor è possibile estendere il servizio con dei nostri metodi custom attraverso quello che viene definito un Service Operation. Per aggiungere una Service Operation basta implementare uno specifico metodo come di seguito:

[WebGet]
public IQueryable<Model.Customers> CustomersInCity(string cityName)
{
    return from c in this.CurrentDataSource.Customers
           where c.City == cityName
           select c;
}

Renderlo accessibile con la configurazione delle autorizzazioni:

public static void InitializeService(IWebDataServiceConfiguration config)
{
...
config.SetServiceOperationAccessRule("CustomersInCity", ServiceOperationRights.All);
}

e potrà essere acceduto attraverso il seguente URL:

http://localhost:2759/WebSite1/Northwind.svc/CustomersInCity?cityName='Rome'

Non soltando è possibile esporre dati ma utilizzando delle Service Operetions è possibile anche sfruttare gli attributi [SingleResult] e [MimeType] per realizzare interessanti combinazioni come ad esempio l'esposizione di template HTML collegati ai dati contenuti nel modello:

[MimeType("text/html")]
[SingleResult]
[WebGet]
public IQueryable<string> WelcomePage()
{
    return new string[]
    {
        "<html><head><title>Welcome</title></head>" +
        "<body><h1>Welcome!</h1><p>Currently we have " +
        this.CurrentDataSource.Customers.Count().ToString() +
        " customers.</p></body></html>"
    }.AsQueryable();
}

Accessibili poi con URL di questo tipo:

http://localhost:2759/WebSite1/Northwind.svc/WelcomePage/$value

Ad esempio è possibile anche creare dei Tempale XAML per Silverlight che possono essere direttamente valorizati con dei dati come nell'esempio precedente e poi caricati dinamicamente nell'applicazione RIA client chiamante utilizzando ad esempio una chiamata XmlHttpRequest con la funzione createfromxaml del plugin.

Abbiamo parlato prima delle due librerie client disponibili per l'accesso via JavaScript e via .NET. Per l'utilizzo AJAX sfruttiamo la libreria JS MicrosoftAjaxDataService.js che ci mette a dsiposizione la classe Sys.Data.DataService . Referenziando la libreria :

<asp:ScriptManager ID="ScriptManager1" runat="server">

<asp:ScriptReference Name="MicrosoftAjaxDataService.js" />

</Scripts>

</asp:ScriptManager>

è possibile utilizzare la libreria per effettuare un query sui dati come di seguito:

var northwindService = new Sys.Data.DataService("/Northwind.svc");

northwindService.query("/Customers", onSuccess, onFailure);

Dove onSuccess e onFailure sono rispettivamente i metodi invocati all'arrivo della risposta o in caso di errore :

function onFailure(error, context, operation) {

$get("spanResults").innerHTML = "Error occurred in operation " + operation + ".";

}

function onSuccess(result, context, operation) {

// Get Customers list and put into a table.

var sb = new Sys.StringBuilder();

sb.append("<table>");

var firstRowOutput = false;

for (idx in result) {

var customer = result[idx];

if (!firstRowOutput) { // Display the header row.

sb.append("<tr>"); for (key in customer) {

if (key != "__metadata") {

sb.append("<th>");

sb.append(key);

sb.append("</th>");

}

sb.append("</tr>");

firstRowOutput = true;

} // Display the data.

sb.append("<tr>");

for (key in customer) {

if (key != "__metadata") {

sb.append("<td>");

sb.append(customer[key]);

sb.append("</td>");

}

sb.append("</tr>");

}

sb.append("</table>");

$get("spanResults").innerHTML = sb.toString();

}

La classe mette poi a disposizione le funzionalità per effettuare update ed insert.

Come già in precedenza segnalato è disponibile anche un namespace client .NET (Microsoft.Data.WebClient) per poter accedere con maggiore semplicità da client managed ai dati esposti da un servizio ASP.NET Data Service .

Attraverso la classe WebDataContext si gestisce il contesto verso uno specifico servizio e con la classe WebDataQuery si rappresentano e si eseguono le query verso la sorgente dati rappresentata da un WebDataContext:

WebDataContext ctx = new WebDataContext(http://localhost:51905/nw.svc);

WebDataQuery<Customer> customers = ctx.CreateQuery<Customer>("/Customer");

foreach (Customer r in customers) {

Console.WriteLine(c.CompanyName );

}

La CTP mette a disposizione anche un generatore di codice (WebDataGen.exe) che, partendo dai metadatid el servizio, ci genera un modello ad oggetti che ci permette di utilizzare LINQ per accedere al servizio:

\Program Files\Microsoft ASP.NET 3.5 Extensions\WebDataGen.exe" /mode:ClientClassGeneration /outobjectlayer:northwind.cs /uri:http://localhost:8090/Northwind.svc

Generato il modello con il tool è possibile utilizzare per accedere ai dati del servizio codice come il seguente:

using System;

using Microsoft.Data.WebClient;

using System.Linq;

using NorthwindModel;

namespace TestApplication {

class Program {

static void Main(string[] args) {

NorthwindEntities ctx = new NorthwindEntities(http://localhost:8090/Northwind.svc);

ctx.MergeOption = MergeOption.AppendOnly;

var q = from c in ctx.Customers where c.City == "London" orderby c.CompanyName select c;

foreach (var cust in q) {

Console.WriteLine(cust.CompanyName);

}

La classe NorthwindEntities deriva da WebDataContext e permette di gestire con LINQ un approccio tipizzato.

Sono possibili anche operazioni di update,delete e insert. L'autenticazione sul servizio avviene passando le credenziali con la classica interfaccia ICredentials.

Conclusioni

ADO.NET Data Service fornisce un nuova nuova sofisticata modalità per esporre , consumare sorgenti dati attraverso un approccio REST che consente di costruire con rapidità servizi in grado di supportare con efficacia le esigenze di accesso ai dati nei nuovi scenari Internet con particolare riferimento alle applicazioni RIA.

Per una introduzione alle funzionalità del servizio vi suggerisco il QuickStart online , il blog del team dove troverete anche le novità in arrivo , e segnalo inoltre alcuni video realizzati sull'argomento:

ADO.NET Data Services - Surfacing Data
ADO.NET Data Services - Querying with URI's
ADO.NET Data Services - A Basic .NET Client
ADO.NET Data Services - A Basic AJAX Client
ADO.NET Data Services - A Basic Silverlight Client

        ADO.NET Data Services - Querying with LINQ
        ADO.NET Data Services - Query Interceptors
        ADO.NET Data Services - Service Operations

ASP.NET ed i Patterns: ASP.NET MVC (Model, View, Controller) Framework (Parte 2)

Giuseppe Guerrasio — Wed, 23 Jan 2008 12:00:00 GMT

Nella prima parte del post ho introdotto il nuovo ASP.NET MVC Framework fino all'implementazione del Controller. Procediamo ora con l'approfondire alcuni elementi relativi all'interazione del Controller con la View che sono tra i principali valori dell'implementazione del MVC.

Nell'ASP.NET MVC Framework il Controller procede a determinare la view da implementare attraverso una Factory che implementa l'interfaccia IViewFactory così definita:

public interface IViewFactory
    {
        IView CreateView(ControllerContext controllerContext, string viewName, string masterName, object viewData);
    }

Questa Factory consente al controller di determinare la view e di poter passare ad essa le informazioni di contesto della richiesta (ControllerContext) e l'oggetto che rappresenta il Model (viewData) .

La View è costruita con una classe che implementa l'interfaccia IView che ha la seguente struttura:

public interface IView
    {
        void RenderView(ViewContext viewContext);
    }

dove il viewContext è la seguente classe che deriva dal ControllerContext:

public class ViewContext : ControllerContext
    {
        public ViewContext(ControllerContext controllerContext, object viewData, TempDataDictionary tempData);
        public ViewContext(RequestContext requestContext, IController controller, object viewData, TempDataDictionary tempData);
        public ViewContext(IHttpContext httpContext, RouteData routeData, IController controller, object viewData, TempDataDictionary tempData);

        public TempDataDictionary TempData { get; }
        public object ViewData { get; }
    }

Avendo derivato il nostro controller dalla classe controller del framework MVC abbiamo a disposizione una serie di metodi e proprietà Helper per innescare la nostra View e fornirgli il Model che indicheremo come viewData come possiamo vedere guardando alla struttura della classe System.Web.MVC.Controller :

public class Controller : IController
{
public Controller();

        public ControllerContext ControllerContext { get; set; }
        public IHttpContext HttpContext { get; }
        public IHttpRequest Request { get; }
        public IHttpResponse Response { get; }
        public RouteData RouteData { get; }
        public IHttpServerUtility Server { get; }
        public TempDataDictionary TempData { get; internal set; }
        public IPrincipal User { get; }
        public IDictionary<string, object> ViewData { get; }
public IViewFactory ViewFactory { get; set; }

        protected internal virtual void Execute(ControllerContext controllerContext);
        protected internal virtual void HandleUnknownAction(string actionName);
        protected internal virtual bool InvokeAction(string actionName);
        protected internal virtual void InvokeActionMethod(MethodInfo methodInfo);
        protected virtual bool OnError(string actionName, MethodInfo methodInfo, Exception exception);
        protected virtual void OnPostAction(string actionName, MethodInfo methodInfo);
        protected virtual bool OnPreAction(string actionName, MethodInfo methodInfo);
        protected virtual void RedirectToAction(object values);
        protected void RedirectToAction(string actionName);
        protected void RedirectToAction(string actionName, string controllerName);
protected void RenderView(string viewName);
        protected void RenderView(string viewName, object viewData);
        protected void RenderView(string viewName, string masterName);
        protected virtual void RenderView(string viewName, string masterName, object viewData);
    }

Ho evidenziato gli elementi della classe direttamente collegati alla gestione della view ed in particolare abbiamo:

- la proprietà ViewFactory sulla quale viene impostata la factory per la costruzione delle view ;

- i metodi Render che permettono di innescare la view fornendo come parametro sia i dati che le informazioni relative al nome della view;

- la proprietà ViewData che è un Dictionary utilizzato per fornire i dati che devono essere presentati al client dalla View.

Nell'implementazione di default del framework del nostro CustomerController, la proprietà ViewFactory viene impostata a runtime nel momento in cui viene assegnata una richiesta e creato il nostro controller e viene valorizzata con la ViewFactory di base del framework System.Web.Mvc.WebFormViewFactory . Possiamo verificarlo mandando in debug la nostra applicazione e analizzando la proprieta sulla classe con il debbugger come di seguito:

Le View generate da questa factory sono essenzialmente della pagine che derivano dalla classe System.Web.Mvc.PageView che come si vede dalla struttura della classe:

public abstract class ViewPage : Page, IView, IViewDataContainer
{
protected ViewPage();

        public AjaxHelper Ajax { get; internal set; }
        public HtmlHelper Html { get; internal set; }
        public string MasterLocation { get; set; }
        public UrlHelper Url { get; internal set; }
        public ViewContext ViewContext { get; }
        public ViewData ViewData { get; }

        protected override void OnPreInit(EventArgs e);
        protected virtual void RenderView(ViewContext viewContext);
        protected internal virtual void SetViewData(object viewData);
    }

Questa non è altro che una particolare pagina aspx (deriva da System.Web.Page come tutte le pagine asp.net) che implementa l'interfaccia IView e l'interfaccia IViewDataContainer che permette la gestione dei dati del modello alla vista:

public interface IViewDataContainer
    {
        object ViewData { get; }
    }

Esiste anche una implementazione della ViewPage che permette di passare alla view le informazioni relative ai dati del model in modo tipizzato:

public abstract class ViewPage<TViewData> : ViewPage
{
protected ViewPage();

public TViewData ViewData { get; }

protected internal override void SetViewData(object viewData);
}

E' evidente che implementando le nostre View e fornendo al controller la nostra ViewFactory possiamo in qualunque momento decidere di implementare delle view alternative come ad esempio una XmlView che fornisca una rappresentazione Xml dei dati nella risposta,oppure utilizzare delle view specifiche per eseguire gli unit test sul controller.

La WebViewFormViewFactory implementata di default sul controller dal framework, prevede che le viewpage siano inserite nella cartella view del sito, all'interno una sottocartella con il nome corrispondente al controller. Se nell'utilizzo del metodo RenderView non vogliamo indicare il nome della viewpage, possiamo anche chiamare la pagina .aspx con il nome della action che è il nome di default che viene utilizzato, altrimenti indicheremo il nome che richiameremo utilizzando lo specifico parametro del metodo RenderView.

Per poter chiudere il nostro piccolo esempio ed avere a disposizione nella view la lista dei customer, procediamo con l'implementare una pagina esattamente come descritto utilizzando il template predefinito. La ViewPage può anche essere una content page e quindi avere a disposizione una page master attraverso le specifiche classi messe a disposizione dal framework.

Come primo test implementiamo una ViewPage tipizzata rispetto alla classe che rappresenta i dati del nostro model ed avremo una nuova pagina che potrà essere invocata attraverso il metodo helper RenderView e le informazione del model potranno essere inserite in nel Dictonary ViewData presente come proprietà nella nostra classe Controller ed utilizzato per passare i dati del model alla view.

Il codice del controller sarà il seguente:

e la ViewPage sarà come di seguito:

E' possibile anche usare un approccio non tipizzato rispetto alla classe che rappresenta i dati del nostro model, ed avremo una nuova pagina che potrà essere invocata attraverso il metodo helper RenderView e le informazione del model potranno essere inserite in nel Dictonary ViewData presente come proprietà nella nostra classe Controller ed utilizzato per passare i dati del model alla view.

Il codice del controller sarà:

Nella ViewPage si potrà accedere alla lista dei customers riferendosi alla ViewData nel seguente modo:

ViewData["List"] as List<Customers>

Nella ViewPage per facilitare la costruzione dei link relativi ad una specifica action è a disposizione una classe di Helper HtmlHelper esposta già alla pagina con la proprietà Html. In particolare attraverso il metodo ActionLink è possibile costruire un link html alla action di uno specifico controller sfruttando la configurazione dell'URL routing. Ad esempio immaginiamo di avere una ulteriore action di nome ViewCustomer che permette di visualizzare i dati di un singolo customers e come parametro accetta un customerid, volendo aggiungere un link a questa action ad ogni elemento della lista della nostra pagina di esempio potremo scrivere :

Html.ActionLink(cn.CompanyName,"CustomerView","Customers")

ottenendo in risposta una stringa contenente il link URL costruito in base all'attuale configurazione del routing ovvero:

http://localhost:64701/Customers/CustomerView

Attraverso uno specifico overload del metodo è possibile passare uteriori parametri sfruttando gli "anonymus type" del linguaggio come dictionary ottenendo la possibilità di aggiungere anche il parametro per estrarre il customer:

<%= Html.ActionLink(cn.CompanyName, new {controller="Customers", action="CustomerView" , id=cn.CustomerID })%>

Ulteriore overload del metodo ci permette di lavorare in modo tipizzato rispetto all'oggetto controller:

<%= Html.ActionLink<MvcApplication1.Controllers.CustomersController> (s=>s.CustomerView (cn.CustomerID ) ,cn.CompanyName)%> </li>

In questo caso viene sfruttato l'expression tree delle lambda expression passate al metodo in modo tipizzato per poter calcolare l'url richiesto per lo specifico controller e la action con i rispettivi parametri in base alla configurazione dell'infrastruttura di url routing.

Scaricando l'MVC Toolkit (download separato dalle ASP.NET extension 3.5) e referenziandolo nel nostro progetto, si hanno a disposizione ulteriori estensioni alla classe HtmlHelper implementate come "Extension Method" . Ad esempio il metodo Select che consente di generare una select Html con il contenuto della sorgente allegata in databinding :

<%= Html.Select("test", ViewData, "CompanyName", "CustomerId")
%>

o il metodo ListBox con cui si ottiene una specifica listbox html :

<%= Html.ListBox ("test", ViewData, "CompanyName", "CustomerId")
%>

e così di seguito per gli altri metodi helper.

Effettuare uno Unit Test del nostro esempio

Avendo a disposizione una infrastruttura che ci ha permesso di implementare in modo completamente separato il controller ed il model dalla view , è possibile implementare degli unit test sul controller senza coinvolgere direttamente tool per il test della UI. E' infatti possibile sviluppare degli unit test come il seguente:

In questo caso con delle specifiche classi abbiamo sostituito il comportamento della classe controller e creato una view di test e possiamo in questo modo effettuare uno unit test del controller senza coinvolgere il resto dell'applicazione e dell'infrastruttura di ASP.NET.

Piccolo approfondimento url routing

Abbiamo visto come nel MVC framework sia presente un'infrastruttura configurabile per il routing delle richieste che arrivano all'applicazione. Questa parte dell'framework è una implementazione del pattern "Front Controller" per determinare in modo configurabile la mappature URL -> Action\Controller.

Tutte le richieste in arrivo vengono agganciate da un HttpModule inserito nella pipeline del HttpRuntime di asp.net che si occupa di inviarle mapparle in base alla configurazione.

La configurazione di quelle che vengono definite le "Route" possibili per il calcolo del controller\action da applicare viene effettuata allo start della Web Application attraverso l'oggetto RouteTable.Routes che con il metoto Add permette di aggiungere ulteriori Route di configurazione.

Le Route rappresentano essenzialmente il mapping tra URL e Type del controller e action che devono essere eseguite per la specifica richiesta.

Aprendo il Global.asax del progetto troviamo le impostazioni di default del framework:

Per poter inserire delle nuove configurazioni occorre quindi costruire una nuova istanza della classe Route , fornirgli i parametri desiderati e appenderla alla collezione che contiene le configurazioni.

Ad esempio per ottenere un mapping di questo tipo:

Customers/ricercaclienti/[query]/[page]

per un controller CustomersController con la seguente action:

[ControllerAction]

public void RisultatiRicerca(string query,int page)

occorrerà aggiungere la seguente Route:

RouteTable.Routes.Add(new Route
{
     Url = "Customers/ricercaclienti/[query]/[page]",
     Defaults = new { controller = "Customers", action = "RisultatiRicerca", page = 0 },
     RouteHandler = typeof(MvcRouteHandler)
});

La classe Route permette anche di utilizzare le RegEx per validare il formato dei parametri utilizzati nella richiesta attraverso l'utilizzo della proprietà UrlRegEx .

L'HttpModule di routing inserito dall'MVC framework utilizza la tabella che contiene le Route per determinare l'Handler a cui passare il compito di creare il controller e gestire il ciclo di vita della richiesta.

La classe impostata sulla proprietà RouteHandler dell'oggetto Route rappresenta un ulteriore punto di intercezione del framework. E' l'elemento che si occupa di fornire l'HttpHandler che utilizzerà la Factory di costruzione del Controller e ad impostare su questo gli oggetti di contesto gestendo il ciclo di vita della richiesta. La classe di default che viene utilizzata dal framewor per questa funzione è la System.Web.Mvc.MvcRouterHandler che ha la seguente struttura:

public class MvcRouteHandler : IRouteHandler
{
public MvcRouteHandler();

protected virtual IHttpHandler GetHttpHandler(RequestContext requestContext);
}

L'interfaccia base che viene utilizzata per interagire con il RouteHandler è la seguente:

public interface IRouteHandler
    {
        IHttpHandler GetHttpHandler(RequestContext requestContext);
    }

dove viene fornito il contesto della richiesta attraverso:

public class RequestContext
{
public RequestContext(IHttpContext httpContext, RouteData routeData);

        public IHttpContext HttpContext { get; internal set; }
        public RouteData RouteData { get; internal set; }
    }

L'Handler che viene restituito di default dalL'MvcRouteHandler è implementato dalla classe:

public class MvcHandler : IHttpHandler, IRequiresSessionState
{
public MvcHandler();

protected virtual bool IsReusable { get; }
public RequestContext RequestContext { get; set; }

        protected internal virtual IController GetControllerInstance(Type controllerType);
        protected internal virtual Type GetControllerType(string controller);
        protected virtual void ProcessRequest(HttpContext httpContext);
        protected internal virtual void ProcessRequest(IHttpContext httpContext);
    }

Implementando una nostra classe di RouteHandler attraverso l'implementazione di IRouteHandler , possiamo inserirci all'interno del processo di caricamento dell'Handler che poi gestisce il ciclo di vita della richiesta controllandolo e cambiandone a piacimento il comportamento.

E' possibile anche sostituire la factory che viene utilizzata per la costruzione del Controller inserendo un ulteriore punto di intercezione.

La factory del controller implementa l'interfaccia System.Web.Mvc.IControllerFactory ed ha questo tipo di definizione:

public interface IControllerFactory

{

IController CreateController(IHttpContext context, RouteData routeData, Type controllerType);

}

per implementarne una nostra e sostituire la classe di default , occorre definire una classe che implementa l'interfaccia e registrarla con l'apposito metodo della classe System.Web.Mvc.ControllerBuilder all'application start nel global.asax:

ControllerBuilder.Current.SetDefaultControllerFactory(typeof(MyControllerFactory));

Conclusioni

Il nuovo MVC Framework offre una nuova infrastruttura basata sul pattern MVC per sviluppare soluzioni Web con ASP.NET completamente integrata con il resto delle funzionalità della piattaforma . Il nuovo framework verrà rilaciato nella ua versione definitiva con le ASP.NET 3.5 Extensions la cui data di rilascio è al momento prevista entro l'estate.

Per poterlo sperimentare un ottimo punto di partenza è rappresentato dal Quickstart on line delle ASP.NET Extension presente online. Interessanti anche i post di Scott sull'MVC Framework e ottimo il Post di Phil Haack post : TDD and Dependency Injection with ASP.NET MVC sull'utilizzo del pattern Dependency Injection e sull'approccio TDD (Test Driven Development) con l'MVC Toolkit .

ASP.NET ed i Patterns: ASP.NET MVC (Model, View, Controller) Framework (Parte 1)

Giuseppe Guerrasio — Mon, 21 Jan 2008 13:30:00 GMT

Con il rilascio in dicembre della prima CTP (Customer Technology Preview) delle nuove ASP.NET 3.5 Extension abbiamo a disposizione la prima versione pubblica del nuovo ASP.NET MVC Framework.

Il MVC (Model, View , Controller) sui cui principi è basato il nuovo ASP.NET MVC Framework è un pattern per sviluppare le componenti di presentation di un'applicazione che ha un ampio utilizzo nel mondo del Web, ne esistono moltissime implementazioni per differenti tecnologie e linguaggi. Il suo successo è essenzialmente dovuto alle caratteristiche implementative che consentono di separare nettamente la logica di controllo e la gestione dei dati del dominio applicativo, dalla modalità con cui vengono presentate le informazioni, rendendo più semplice manutenzione e test dell'applicazione.

In passato abbiamo visto nascere diversi tipi di framework più o meno validi per sviluppare applicazioni ASP.NET con il pattern MVC , la vera differenza del nuovo ASP.NET MVC Framework consiste in una vera e propria integrazione del modello nell'infrastruttura delle pagine dinamiche di .NET. Il nuovo framework, infatti, trova spazio all'interno del namespace System.Web con uno specifico namespace System.Web.Mvc e si propone di diventare una vera e propria alternativa al classico modello di sviluppo delle pagine web con .NET, per quei casi in cui la separazione della logica di controllo e degli oggetti del nostro dominio applicativo, dalla presentazione svolgono un ruolo determinate, o dove si vuole utilizza un approccio basato su un maggior livello di test del codice o addirittura uno sviluppo TDD (Test Driven Development).

Overview dell'ASP.NET MVC Framework

L'infrastruttura classica per sviluppare pagine Web con ASP.NET è essenzialmente basata sul pattern "Page Controller" utilizzato come base concettuale di funzionamente dalle principali infrastrutture per lo sviluppo di pagine Web dinamiche. Le richieste (URL) indirizzate ad ASP.NET vengono gestite dal runtime della piattaforma che assegna l'esecuzione della risorsa richiesta ad una pagina .aspx. La pagina implementa il suo ciclo di vita gestito con una serie di eventi predefiniti che eseguono il "Page Controller" . In questo modo lo sviluppo dell'applicazione è rapido e semplice, ma si legano in modo determinante gli url richiesti alle pagine che implementano sia alla parte di logica che di presentazione vera e propria, rendendo di fatto più difficili tutte le attività di test, evoluzione e manutenzione dell'applicazione.

In particolare le difficoltà collegate alla costruzione di unit test rappresentano uno dei più significativi limiti portati da questo tipo di pattern. Essendo, infatti, l'implementazione del controller, strettamente legata alla pagina e quindi all'ambiente in cui la pagina vive (HttpContext e tutti gli altri elementi di contesto e funzionamento della pagina e di ASP.NET) , diventa praticamente impossibile sia realizzare uno sviluppo TDD che gestire dei semplici unit test sulla parte di logica del controller.

Per approfondire l'implementazione del "Page Controller" in ASP.NET vi suggerisco di leggere Implementing Page Controller in ASP.NET .

Nell' ASP.NET MVC Framework vengono realizzati ed applicati i principi base del pattern MVC ovvero la netta separazione tra i tre elementi fondamentali che concettualmente lo compongono:

- Model: Gestisce il modello di oggetti che rappresentano i dati nel nostro Dominio Applicativo e fornisce la logica per la gestione dei dati. Nelle applicazioni più semplici basate su ASP.NET può essere anche un normale Dataset.

- View: Gestisce le modalità di presentazione dei dati attraverso il model che gli viene assegnato

- Controller: E' l'elemento principale del pattern, si occupa di gestire la richiesta e di coordinarne la logica di esecuzione utilizzando Model e selezionando la View da associare per la risposta .

Esistono diverse sfumature nell'MVC ma nelle implementazioni Web di questo pattern viene utilizzato principalmente l'MVC con view passiva ed il flusso è genericamente quello rappresentato nel seguente disegno:

La richiesta ad uno specifico URL viene assegnata ad un Controller che implementa la logica di esecuzione delle azioni necessarie a fornire la risposta al client. Il Controller utilizza il Model per rappresentare i dati necessari alla risposta, li associa ad una View con cui non è strettamente collegato ed a cui assegna il compito di presentarli al richiedente.

In particolare nella definizione dell'architettura del nuovo framework MVC per ASP.NET uno dei principali elementi di attenzione è stato posto nel principio di Estendibilità che è anche alla base dell'ottenimento di un'infrastruttura più semplicemente testabile. L'intera architettura, infatti, fà un ampio uso di interfacce e factory per praticamente l'intera gamma di elementi che la compongono. La costruzione del controller e della view, avviene attraverso delle specifiche factory che, attraverso la sostituzione delle stesse e l'utilizzo di pattern come il Dependency Injection, permettono lo sviluppo di sofisticati ambienti di test per il codice ed una grande flessibilità nell'architettura.

Ulteriore esempio di flessibilità inserito nel framework non propriamente collegato al pattern MVC è rappresentato dall'engine di routing che consente la mappatura degli URL con la specifica classe Controller che ne deve gestire l'esecuzione e l'indirizzamento della View per produrre la risposta.

Il seguente disegno rappresenta una semplificazione del ciclo di esecuzione di una richiesta all'interno dell'ASP.NET MVC Framework :

La richiesta viene intercettata da un HttpModule specifico inserito dal framework MVC (UrlRoutingModule) e indirizzata alla componente che si occupa di effettuare il routing che, in base all'URL ed alla sua configurazione, individua un oggetto Route che rappresenta il match tra richiesta e il controller che deve gestirla.

L'oggetto Route utilizza il RouteHandler ad esso associato, assegna l'esecuzione della richiesta ad un controller creandone un'istanza attraverso una specifica factory ed esegue il metodo sul controller associato all'azione specifica che il controller deve eseguire.

Il controller riceve il contesto della richiesta, esegue l'azione e utilizzando il model prepara i dati da passare alla view che viene innescata su richiesta attraverso una specifica factory.

La View costruisce la risposta che viene inviata al browser.

Un esempio pratico per la gestione di una richiesta con l' ASP.NET MVC Framework

Proseguiamo nell'illustrare le componenti del framework con un piccolo esempio con il quale vogliamo implementare una semplice applicazione Web per ricercare informazioni sui nostri clienti. Per il momento trascuriamo il funzionamento dell'infrastruttura di routing su cui torneremo dopo e la utiliziamo con la sua configurazione di default.

Per poter sviluppare con Visual Studio un'applicazione MVC occorre selezionare lo specifico template di progetto Web:

L'organizzazione e gli artifatti prodotti dal template di progetto si presentano come di seguito :

Vengono create le seguenti cartelle:

\Content per i contenuti grafici e di stile

\Controllers per l'inserimento del codice delle classi Controller

\Models per contenere le classi models del progetto

\Views per le classi view , contiene una sotto cartella per ogni controller e una view per ogni action

La configurazione di default impostata per il routing associa l'url al controller attraverso la seguente modalità:

/[Controller]/[Action]?paramname1=paramvalue1,.....

Dove [Controller] è il nome della classe che implementa il controller stesso per la specifica richiesta, [Action] rappresenta l'azione che deve essere eseguita sul controller ed i parametri vengono inseriti nel contesto della richiesta come valori che la action deve utilizzare o come parametri di input per l'esecuzione. Vedremo successivamente che implementando opportunamente la action è anche possibile passare dei parametri con il formato:

/[Controller]/[Action]/[id]

Ad esempio nel caso in cui abbiamo una richiesta in cui l'url è /Customers/.... con la configurazione di default descritta verrà ricercata una classe controller di nome CustomersController che sarà la classe che utilizzeremo per gestire le azioni collegate ai nostri clienti.

Per poter implementare una classe come controller occorre implementare l'interfaccia System.Web.MVC.IController che viene usata come contratto con il resto dell'infrastruttura del framework e per ricevere il contesto della richiesta che viene rappresentato con la classe System.Web.MVC.ControllerContext. L'interfaccia IController ha la seguente struttura:

public interface IController
    {
        void Execute(ControllerContext controllerContext);
    }

La classe ControllerContext è definita come di seguito :

public class ControllerContext : RequestContext
    {
        public ControllerContext(RequestContext requestContext, IController controller);
        public ControllerContext(IHttpContext httpContext, RouteData routeData, IController controller);

public IController Controller { get; }
}

e contiene le informazioni necessarie al gestire il contesto dell'esecuzione , abbiamo il Controller assegnato e la classe System.Web.MVC.RequestContext definita come di seguito:

public class RequestContext
{
public RequestContext(IHttpContext httpContext, RouteData routeData);

       public IHttpContext HttpContext { get; internal set; }
       public RouteData RouteData { get; internal set; }
   }

Questa classe contiene in particolare:

- i dati di routing determinati in base all'url

- il contesto della richiesta ASP.NET gestita con la classica HttoContext

In particolare l'HttpContext viene in questo caso agganciato partendo dall'interfaccia System.Web.IHttpContext per permetterne una sostituzione sia di questa che delle interfacce IHttpRequest e IHttpResponse in fase di unit test senza dover derivare dalle classi base dell' infrastruttura di ASP.NET.

Per semplificarne la costruzione di un Controller si può derivare dalla classe System.Web.MVC.Controller che oltre al metodo Execute implementa una serie di funzionalità e di metodi helper che permettono di sviluppare concentrandoci sulla logica del controller riducendo al minimo il codice di infrastruttura necessario.

Abbiamo già detto che ogni controller può implementare una o più Action che rappresentano le azioni che possono essere eseguite sul controller e che nella configurazione di default del routing vengono, come sopra descritto, rimappate sull'url richiesto.

Ad esempio l'url /Customers/List che useremo per avere una lista di tutti i nostri clienti, viene interpretato con esecuzione della action "List" sul Controller CustomersController .

Le Action vengono associate ai metodi marcati con lo specifico attributo System.Web.MVC.Controller .

Nel nostro esempio, quindi, per poter implementare il controller Customers implementeremo la seguente classe:

Ogni controller implementa anche una Action di base che viene nella configurazione di default associata alla action Index e che è quella che viene eseguita in assenza di informazioni di routing relative alla action nell'url come ad esempio nel caso di una URL : /Customers.

Alla nostra action possono essere passati anche dei parametri che possono essere estratti attraverso l'utilizzo dell'oggetto di contesto della richiesta. Infatti, come abbiamo già visto sopra, quest'ultimo implementa IHttpcontext di ASP.NET e quindi contiene l'oggetto che rappresenta la richiesta implementando IHttpRequest.

Avendo derivato il nostro oggetto dalla classe Controller abbiamo già a disposizione la proprietà Request sulla nostra classe che ci permette di accedere direttamente all'oggetto Request del contesto della richiesta arrivata al controller.

Ad esempio con una richiesta di url in cui vogliamo passare un parametro per paginare i dati estratti ed estrarre la pagina 1 della lista clienti: /Customers/List?page=1 possiamo dall'interno del nostro metodo di action estrarre il parametro nel seguente modo:

this.Request["page"];

sapendo che lo utilizzeremo come un int :

int i = Convert.ToInt32(this.Request["page"]);

E' possibile anche utilizzare un formato per il metodo della action che preveda già direttamente i parametri come ad esempio:

In questo caso potrà essere usato il formato di URL seguente : /Customers/List/1 ed il parametro successivo a list verrà direttamente associato al parametro del metodo perchè previsto dalla configurazione di default dell'url routing.

Agendo sulla configurazione del routing, come vedremo, si possono cambiare questi comportamenti nella gestione dei paramentri, aggiungerne ed inserire anche dei validatori sull'url che vengono eseguiti prima di innescare il controller.

Per costruire il Model del nostro esempio, utiliziamo LinqToSql e procediamo a mappare una classe Customers sulla tabella omonima del database Northwind.

LinqToSql ci costruisce l'infrastruttura di classi necessaria derivandola dai metadati del database. Possiamo quindi procedere ad utilizzare le classi che sono state generate dai tool di visual studio ed implementare il segente metodo GetCustomers nel NorthwindDataContext che verrà usato dal controller per estrarre la lista dei clienti:

Terminata l'implementazione del Model e della logica della nostra Action , l'ultimo passo consiste nell'associare il model alla view che dovrà rappresentarlo.

Nella seconda parte del post procederò con il descrivere questa parte dell'implementazione del MVC Framework con qualche approfondimento anche sull'infrastruttura di routing.

Articoli sulle nuove funzionalità di WCF e IIS 7

Giuseppe Guerrasio — Thu, 27 Dec 2007 15:43:00 GMT

Breve post per segnalare due interessanti articoli presenti su MSDN Magazine di Gennaio. Il primo è relativo al nuovo supporto per WCF in .NET 3.5 per i Web Service stile REST e le funzionalità di Syndications—RSS :

http://msdn.microsoft.com/msdnmag/issues/08/01/WCFinOrcas/default.aspx

Il secondo articolo è relativo alla nuova pipeline di IIS 7 :

http://msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7/default.aspx

ASP.NET e paginazione dei dati con le Grid

Giuseppe Guerrasio — Mon, 21 May 2007 10:52:00 GMT

Mi capita spesso di incontrare gruppi di sviluppo che lavorano con ASP.NET e che lamentano problemi di performace che poi ad una analisi più approfondita , risultano essere dipendenti dall'utilizzo di tecniche di paginazione scorrette su tabelle o viste di dati contenenti una grande quantità di righe. Le problematiche più ricorrenti riguardano un uso scorretto del meccanismo automatico di paginazione e del ViewState (a volte addirittura memorizzato nella sessione) . Di seguito segnalo alcune risorse utili ad indirizzare questo tipo di problematiche in modo corretto, mantendo buona parte degli automatismi forniti dai controlli ASP.NET:

Paginazione in SQL Server 2000 ed altri cosigli sulle performance articolo datato ma con spunti utilissimi:

http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/default.aspx

Control State - View State

http://msdn2.microsoft.com/en-us/library/z1hkazw7.aspx

Paging Data usando Sql 2005 ROW:NUMBER()

http://weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx