blogs.ASPItalia.com

ASPItalia.com sulla strada verso Windows 8

Cristian "Ricciolo" Civera — Thu, 10 Nov 2011 20:32:00 GMT

Fornita la Developer Preview di Windows 8, non si pu� resistere alla tentazione di provare e testare le WinRT e Visual Studio 2011. Il nostro gruppo lo sta facendo con qualcosa di pratico che ormai � diventato la nostra palestra di sviluppo: l'applicazione client di ASPItalia.com.

Dopo averla sviluppata per Windows Phone 7 con le tecniche e i framework in cui crediamo abbiamo deciso di cominciare un cammino di porting anche verso Metro. C'� da dire che la facilit� e il riutilizzo delle proprie conoscenze sono un grosso punto a favore ed � bastato poco per vedere gi� dei risultati. Eccoli:

Io e Daniele, in occasione di WPC 2011, metteremo a disposizione la nostra esperienza nella sessione che terremo. Vi invitiamo quindi a partecipare, perch� sar� molto interessante.

Tags: .NET Framework, .NET Framework 4.5, Metro, WinRT

Continua a leggere ASPItalia.com sulla strada verso Windows 8.

Prestazioni delle query LINQ in architetture complesse

Cristian "Ricciolo" Civera — Mon, 30 May 2011 09:39:00 GMT

In un post precedente ho parlato dell'interfaccia IQueryable e dell'utilit� che pu� avere se passata tra i vari strati dell'applicativo, dal repository fino ai servizi applicativi. La tecnica � molto comoda ed elegante, ma comporta alcuni problemi, uno dei quali � la scelta delle navigation property da materializzare, che per l'appunto ho risolto con una tecnica illustrata nel post menzionato.

Nell'esperienza da me fatta mi sono per� un giorno ritrovato con una query dalle prestazioni davvero scadenti. La query in questione impiegava 6 secondi per ottenere una sola entit� con molteplici navigation property da caricare perci� subito ho dato la colpa a SQL Server. Guardo la query TSQL con SQL Profiler, la eseguo e noto con sorpresa che su SQL Sever essa viene eseguita in un istante, perci� ripiego su Entity Framework che, sebbene i dati non siano tanti, impiega molto tempo nell'analisi della view e nella preparazione della query. Faccio quindi un test compilando la query con la classe CompiledQuery, come da best practice, e ottengo cos� prestazioni ottime. Il problema � che in una soluzione a strati, le query compilate non si possono usare, perch� solo chi consuma i dati conosce la query managed e la dovrebbe compilare, ma cos� facendo si accoppierebbe al tipo di repository. La prima soluzione che ho pensato � di creare metodi specifici sull'interfaccia di repository, tipo "DammiOrdineConDettaglioECliente", perdendo per� i benefici di IQueryable e creando operazioni ripetitive. Ho quindi cercato un'altra strada riprendendo la stessa tecnica dell'extension method include.

Sempre nel post precedente ho mostrato come possiamo metterci in mezzo, tra la query ed Entity Framework, per manipolarla prima che venga passata al motore. Ho applicato quindi lo stesso concetto intervenendo anche in questo caso sull'interfaccia IQueryProvider. Ipotizzando di avere una query tipo:

int n = 1;
customers.Where(c => c.Orders.Count > n)

l'idea � quella di intervenire prima di eseguirla e di:

renderla generica in modo da essere indipendente da variabili e parametri;
guardare in cache se � presente il delegate oppure compilare la query;
invocare la funzione passando le variabili e i parametri.

Per il primo passaggio uso un expression visitor anche in questo caso che trasforma la query precedente in questa:

Convert(Param_0.Customers).Where(c => (c.Orders.Count > Param_1))

Come si vede, la query � stata parametrizzata per accettare l'ObjectContext e il valore di confronto che � esterno alla query (la variabile n). A questo punto uso il ToString dell'expressione stessa, come chiave per fare lookup su un dizionario di chiave/delegate. Se non lo trovo uso la classe CompiledQuery, individuo il metodo adatto per il numero di parametri generici da passare, compilo la query e salvo il delegate nel dizionario. Per farvi capire, di seguito il codice che uso per la compilazione:

public Delegate Compile(IEnumerable<ParameterExpression> parameters, Type returnType)
{
  // Preparo i parametri della lambda mettendo in coda il tipo ritornato
  Type[] types = parameters.Select(p => p.Type).Concat(new Type[] { returnType }).ToArray();

  // Ottengo il tipo di delegate
  Type funcType = Type.GetType(String.Format("System.Func`{0}, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", types.Length));
  if (funcType == null)
    funcType = Type.GetType(String.Format("System.Func`{0}, System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", types.Length), true);
  funcType = funcType.MakeGenericType(types);

  // Creo la lambda in base al tipo
  var lambda = Expression.Lambda(funcType, expression, parameters);

  // Chiamo il metodo compile specifico
  MethodInfo method = typeof(CompiledQuery).GetMethods(System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.Public)
    .FirstOrDefault(n => n.Name == "Compile" && n.IsGenericMethod && n.GetGenericArguments().Length == types.Length);
  Delegate compiledFunction = (Delegate)method.MakeGenericMethod(types).Invoke(null, new object[] { lambda });

  return compiledFunction;
}

A questo punto devo invocare il delegate, perci� riprendo i parametri della query corrente da eseguire e li passo al delegate, ottenendo cos� il risultato.

Cos� facendo metto dell'overhead per la traduzione della query, ma i benefici che ottengo dalla compilazione sono ben superiori, il tutto trasparente ai vari strati. Sto preparando una libreria che contenga queste estensioni, supporti Code first e permette di pluggare manipulatore ed esecutori della query; presto la metter� online.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, .NET Framework 4.0, Architettura, Entity Framework, LINQ

Continua a leggere Prestazioni delle query LINQ in architetture complesse.

Real Code Day 6: Windows Azure e MVVM su Windows Phone 7

Cristian "Ricciolo" Civera — Wed, 25 May 2011 14:18:57 GMT

La sesta edizione del nostro evento che si concentra sul codice � da poco passato e vorrei riassumere la giornata per quanto riguarda le mie sessioni.

Innanzitutto credo che il bilancio sia decisamente positivo; come gi� detto e dalle testimonianze dei partecipanti, la location era davvero ottima, confortevole e la fase di registrazione � andata per il meglio.

Nel corso della giornata ho tenuto pi� sessioni alcune delle quali con altri del gruppo. Prima di tutto con Daniele abbiamo visto le novit� pi� importanti di HTML5 senza esagerare e restando sulle specifiche che sono mature. In particolare ho mostrato con Daniele il tag video facendo vedere pregi e difetti, dando un occhio ai player gi� preconfezionati per HTML5 sviluppati in HTML, JavaScript e CSS: in ModelVC abbiamo utilizzato MediaElement.js

E' stata poi la volta delle sessioni rapide. In 20 minuti ho presentato Windows Azure, i servizi che fornisce e come con pochi click � possibile prendere un'applicazione web preesistente e portarla su Azure. Questa piattaforma forza il modo di pensare le applicazioni, in modo che siano scalabili il pi� possibile, e il messaggio che cerco sempre di trasmettere � quello di almeno informarsi su questa piattaforma e prenderla in considerazione per i nuovi sviluppi o per eventuali migrazioni, invece di scartarla con scetticismo, poich� pu� riservare sorprese, anche dal punto di vista economico.

Con tutta la ciurma di 5DLabs, poi, ho tenuto una sessione su Windows Phone 7. La prima parte l'ho dedicata a presentare il pattern MVVM e come realmente nel nostro gruppo lo utilizziamo per lavorare insieme ed essere produttivi. Di tutto questo potete trovare il materiale a questo indirizzo.

In conclusione sono molto soddisfatto della giornata, ho incontrato molta gente interessata alle tematiche e un doveroso grazie ai miei compagni di avventura con cui � sempre un piacere trascorrere il tempo libero e lavorativo.

Tags: .NET Framework, .NET Framework 4.0, Architettura, HTML5, Windows Azure, Windows Phone, Windows Phone 7

Continua a leggere Real Code Day 6: Windows Azure e MVVM su Windows Phone 7.

LINQ, lazy loading e architettura

Cristian "Ricciolo" Civera — Fri, 11 Mar 2011 17:42:00 GMT

Con l'avvento di LINQ l'accesso ai dati � decisamente cambiato. Con un timido LINQ to SQL e un po' pi� maturo LINQ to Entities abbiamo potuto interrogare le informazioni sfruttando ORM, oggetti, tipizzazione, compilazione delle query e tutti i benefici che ormai sappiamo.

Anche LINQ con il tempo ha dovuto trovare il suo posto e adattare/adattarsi hai layer e ai pattern che usiamo da tempo e, a mio avviso, si � trovato un ottimo compromesso che permetta di conciliare astrazione e la facilit� di LINQ. Mi riferisco alla tipica separazione in layer che solitamente si fa tra repository, servizi di dominio e servizi applicativi che ha trovato alleato l'utilizzo dell'interfaccia IQueryable per essere restituito dal repository e permette ai vari strati di aggiungere pezzi alla query per poter essere poi eseguita quando effettivamente la consumiamo.

Il nostro MarcoDes ha inserito questa tecnica in Model Virtual Casting, e si dimostra molto comoda ed efficace se utilizzata con LINQ to Entities. Non voglio per� parlare di questo dal punto di vista architetturale ma affrontare un problema tecnologico che ho dovuto affrontare. Quando infatti utilizziamo IQueryable ci ritroviamo con la problematica principale di dover indicare quali navigation property caricare all'interno delle entit� che si stanno materializzando e, scartando l'ipotesi del lazy loading per motivi di controllo ed efficienza sulle query, si procede con l'indicare sul repository le propriet� da includere. Anche questo � implementato in Model Virtual Casting e l'abbiamo rappresentato con un'interfaccia simile a questa.

public interface IReadOnlyRepository<T>
{
  IQueryable<T> GetAll();
  IReadOnlyRepository<T> Include(string path);
}

Esiste una variante che al posto della stringa richiede un Expression per rendere tutto tipizzato, ma in sostanza il discorso non cambia. Quando da un servizio utilizziamo il repository di fatto faremo:

IQueryable<Product> list = new ProductRepository().Include("Orders").GetAll();

In questo modo, quando sfogliamo list otteniamo popolata la classe Product con i rispettivi ordini attraverso la collezione esposta dalla propriet� Orders. Poich� l'implementazione del repository � basta su EF 40, la chiamata ad Include si traduce semplicemente alla chiamata alla funzione omonima di ObjectQuery<T> di LINQ to Entities.

Il problema di questo � approccio � che qualora decidiamo di restituire la variabile list, facendola passare ad esempio dallo strato dei servizi a quello applicativo per effettuare un binding, perdiamo il riferimento al repository e di conseguenza la possibilit� di aggiungere Include anche su strati successivi. Se gli strati che si passano IQueryable e alterano la query non fanno altro che agire solo sull'expression tree, non � pi� probabile che sia l'utilizzatore finale a sapere quali propriet� si debba materializzare? A mio modo di vedere la risposta � s� e lo dimostra anche il fatto che spesso si utilizzano proezioni per ottenere un sottoinsieme dei membri disponibili su una classe.

Per permettere quindi di effettuare gli Include su tutti gli strati ho pensato dapprima a la creazione di un'inferfaccia IMultiQueryable<T< che ereditando da IQueryable permetta sia di effettuare query ma anche di effettuare Include. Questa soluzione l'ho adottata con un cliente e si � dimostrata sempre funzionante portando solo con se la scomodit� di fare il cast in certe situazioni su IMultiQueryable. Ho dunque pensato ad una soluzione alternativa che praticamente consiste nel creare un extension method personalizzato per rappresentare l'include:

public static IQueryable<T> Include<T>(this IQueryable<T> source, params Expression<Func<T, Object>>[] properties)
{
  MethodInfo method = ((MethodInfo)MethodBase.GetCurrentMethod()).MakeGenericMethod(new Type[] { typeof(T) });
  var arguments = new Expression[] {
    source.Expression,
    Expression.NewArrayInit(typeof(Expression<Func<T, Object>>), properties.Select(p => Expression.Quote(p))),
  };

  return source.Provider.CreateQuery<T>(Expression.Call(null, method, arguments));
}

In modo simile a Where, OrderBy ecc, non faccio altro che creare un'espressione che chiama il metodo stesso Include. Questo mi permette di eliminare tale metodo dall'interfaccia di repository e di scrivere, ovunque sono, il seguente codice:

IQueryable<Product> list = GetProductsFromRespository();
list = list.Include(p => p.Orders).Take(10).Include(p => p.Details);

Possiamo quindi combinare Include come qualsiasi altro extension method, su qualsiasi layer, basta che sia un IQueryable. E' chiaro per� che cos� facendo quando LINQ to Entities dovr� convertire l'expression tree in SQL, non conoscer� il nostro metodo personalizzato e lancer� un'eccezione. Aggirare il problema per� � pi� semplice di quanto si pensi, perch� basta fornire un intermediario all'oggetto iniziale della query.

Mettendoci a livello del repository possiamo infatti non restituire direttamente l'ObjectQuery restituito dall'ObjectContext di EF, ma restituire un wrapper da noi creato che implementa IQueryable.

public IQueryable<Product> GetAll()
{
  NorthwindContext c = new NorthwindContext();
  return new ObjectMultiQuery<T>(c.Products);
}

Implementare IQueryable se si deve fare solo da intermediari � piuttosto semplice, perch� la nostra unica intenzione � porci in mezzo prima di eseguire la query su database. Per farlo dobbiamo implementare IEnumerable.GetEnumerator e IQueryProvider.Execute, alterare l'espression tree creato e passarlo al motore di LINQ to Entities per eseguirla.

public IEnumerator<T> GetEnumerator()
{
  // Trasformo l'espressione per LINQ to Entities
  IncludeVisitor compiler = new IncludeVisitor();
  Expression newExpression = compiler.Visit(this.Expression);

  // Creo la nuova query utilizzando ObjectQuery<T>
  IEnumerable<T> result = this.original.Provider.CreateQuery<T>(newExpression) as IEnumerable<T>;

  // Ottengo il risultato
  return result.GetEnumerator();
}

Il campo original � l'oggetto originale EF ottenuto con c.Products nel codice precedente e rappresenta l'engine di EF. La classe IncludeVisitor invece ha il compito di trasformare l'espressione, cio� tradurre le chiamate all'extension method Include, al metodo ObjectQuery.Include. Ci viene in aiuto la classe ExpressionVisitor dalla quale possiamo ereditare e sovrascrivere il metodo VisitMethodCall per cambiare l'espressione di chiamata. Riporto il codice con i commenti cos� da capire meglio come funziona:

class IncludeVisitor : ExpressionVisitor
{
  protected override Expression VisitMethodCall(MethodCallExpression node)
  {
    if (node.Method.DeclaringType == typeof(Extensions) && node.Method.Name == "Include")
    {
      PropertiesVisitor visitor = new PropertiesVisitor();

      // ObjectQuery<T>
      Type objectQueryType = typeof(ObjectQuery<>).MakeGenericType(node.Arguments[0].Type.GetGenericArguments());
      // Visito il context così conto anch'esso come parametro
      // Effettuo un convert per essere sicuro che sia un ObjectQuery<T>
      Expression exp = Expression.Convert(this.Visit(node.Arguments[0]), objectQueryType);

      // Trovo il metodo include specifico di ObjectQuery<T>
      MethodInfo includeMethod = objectQueryType.GetMethod("Include", BindingFlags.Public | BindingFlags.Instance);

      // Chiama il metodo Include per tutte le espressioni passate
      foreach (var property in ((NewArrayExpression)node.Arguments[1]).Expressions)
      {
        visitor.FindProperties(property);

        // Concateno le proprietà trovate con il punto
        exp = Expression.Call(exp, includeMethod, Expression.Constant(String.Join(".", visitor.PropertyNames)));
      }

      return exp;
    }
    return base.VisitMethodCall(node);
  }
}

In questo modo l'expression tree originale cambia cos�:

// Da
Convert(value(System.Data.Objects.ObjectSet`1[Product])).MergeAs(AppendOnly).Include(new [] {c => c.Orders}).Take(10)
// A
Convert(Convert(value(System.Data.Objects.ObjectSet`1[Product])).MergeAs(AppendOnly)).Include("Orders").Take(10)

Trovo questa soluzione veloce ed efficace ed � soprattutto approvata da MarcoDes :-D. Trovate l'esempio nelle demo di Codemotion 2011 svoltosi a Roma pochi giorni fa. Enjoy!

Tags: .NET Framework, .NET Framework 3.5, .NET Framework 4.0, Architettura, Entity Framework, LINQ, LINQ to Entities

Continua a leggere LINQ, lazy loading e architettura.

Push notification per Windows Phone con il .NET Framework

Cristian "Ricciolo" Civera — Sun, 02 Jan 2011 19:18:00 GMT

Scrivo questo post per segnalare un piccolo problema in cui ci si pu� imbattere se si vuole mandare notifiche ad un device. Su MSDN o per la rete si trovano piccoli esempio che preparano l'XML per toast o tile concatenando il testo. Siamo nel 2011 e direi che � ora di scrivere il codice bene utilizzando uno dei molteplici modi che il .NET Framework mette a disposizione, come LINQ to XML, ed evitare problemi di caratteri speciali.

Nel mio codice ho dovuto quindi, una volta preparato l'XML, salvarlo in uno Stream per poi tenermi i byte da inviare con WebClient o WebRequest, con qualcosa simile a questo:

using (MemoryStream stream = new MemoryStream())
{
  using (XmlWriter writer = XmlWriter.Create(stream, settings))
  {
    doc.Save(writer);
    writer.Flush();

    data = stream.ToArray();
  }
}

Inviando poi la variabile data con un POST le notifiche per� non arrivavano. Debuggando una toast notification mentre l'app era attiva, ricevevo una eccezione che per� non potevo intercettare, perch� generata da codice della libreria Microsoft. Dopo vari tantitivi ho capito che il problema stava nel preamble dell'encoding: tre byte inseriti all'inizio dello Stream per indicare il tipo di codifica utilizzata per il testo XML. Sebbene non dovrebbe essere un problema a Windows Phone, a lui non piace e dato che usavo un UTF8 e l'encoding viene letto dall'header HTTP, ho dovuto rimuovere questa informazione creando l'encoding a mano e passando il parametro di preamble a false.

byte[] data;
Encoding encoding = new UTF8Encoding(false);

XmlWriterSettings settings = new XmlWriterSettings();
settings.Encoding = encoding;

using (MemoryStream stream = new MemoryStream())
{
  using (XmlWriter writer = XmlWriter.Create(stream, settings))
  {
    doc.Save(writer);
    writer.Flush();

    data = stream.ToArray();
  }
}

Spero vi sia utile.

Tags: .NET Framework, .NET Framework 4.0, Windows Phone, Windows Phone 7, XML

Continua a leggere Push notification per Windows Phone con il .NET Framework.

Take Me Back e l'architettura

Cristian "Ricciolo" Civera — Wed, 22 Dec 2010 21:15:00 GMT

I miei compagni di avventura Alessio e Marco vi hanno gi� introdotto a Take Me Back: la nostra prima applicazione OzoSoftware. Con questo e altri post vorrei parlarvi delle tecniche impiegate per la realizzazione dell'applicazione di cui, per metodologia di sviluppo, impegno e risultato vado molto fiero.

Partiamo dall'architettura che sfrutta un framework appositamente sviluppato per facilitarci appositamente nello sviluppo di applicazioni per Windows Phone 7, usato poi nell'applicazione per ASPItalia.com. Senza grosse pretese, non abbiamo abbondato di astrazione, ma ci siamo limitati (per ora) alle tecniche pi� classiche di architettura che si usano con Silverlight, adattandole leggermente. Prima di tutto � basato su MVVM, sviluppando classi base, mediator pattern e classi pi� core (che colmano la mancanza di certe API perch� basato su SL 3.0) create da un fork del MVVM Light Toolkit.

Ci siamo concentrati nello sviluppare i view model in modo che siano completamente testabili, perci� tutti gli aspetti che riguardano MessageBox, gestione errori, canale notifiche, task e chooser, sono affidati dal mediator pattern, di cui parlo in questo articolo: lancio il messaggio e qualcuno, la parte legata alla view, agisce di conseguenza.

La variazione sul tema MVVM risiede nell'associazione View-ViewModel. Poich� � nel ViewModel che eseguo i comandi e spesso l'attivit� � quella di navigare tra le pagine, abbiamo scelto di sviluppare un oggetto ViewModelApplication che tramite il metodo NavigateToViewModel permette di navigare ad un'altra pagina. In un'applicazione Windows Phone di fatto ogni pagina (la view) ha il suo ViewModel e solitamente la navigazione � richiesta da esso. Richiedendo la navigazione per ViewModel, posso istanziarlo come voglio (al volo, IoC, ecc) e passare parametri che possono servire al ViewModel da mostrare. Di fatto il ViewModelApplication � un controller pluggabile per la navigazione tra pagine. Il bello � affidato al IViewBinder, la cui implementazione predefinita risolve la View a cui navigare via reflection. Se richiediamo di navigare quindi ad un'istanza o al tipo MapViewModel, il frame navigher� all'uri MapView.xaml.

ViewModelApplication.NavigateToViewModel(new MapViewModel());

Il controller che gestisce quindi la navigazione tra le pagine ci permette di avere un po' di funzionalit� in pi� che fanno molto comode. Prima tra tutte la possibilit� di implementare l'interfaccia IViewModelNavigation sul VM per gestire gli eventi di navigazione NavigatingFrom, NavigatedFrom, NavigatedTo, comodo per avviare il caricamento delle informazioni o fermarle quando si esce dalla pagina. Poi la possibilit� di implementare l'interfaccia IPersistable, per salvare o caricare le informazioni per il tombstoning. E' tutto automatizzato, se la pagina si chiude viene chiamato il SaveState, se si riapre il LoadState; se il ViewModel infatti rappresenta le informazioni da mostrare tramite la View, � in esso che vanno persistite o mostrate.

Poich� alcune informazioni sono condivise tra pi� ViewModel � difficile determinare chi ha il compito di salvarle nella fase di tombstoning, per cui abbiamo optato per creare della classi singleton che si autogestiscono. Implementando la classe IKeyPersistable si registrano al motore con ViewModelApplication.RegisterPersistable per partecipare anch'esse alla fase di tombstoning. Tutto questo ha semplificato notevolmente la gestione del tombstoning, perch� affidata ad ogni parte a cui compete. Non serve neanche un locator dei ViewModel perch� questi sono sempre indipendenti tra loro o eventualmente lavorano con intermediari sopra citati.

Per quanto riguarda infine il supporto a Blend, ci limitiamo ad usare il DataContext del namespace di design di blend, utilizzando la voce "Create Sample Data From Class" che ci assicura di avere il supporto a design time allineato al ViewModel sottostante.

Nel prossimo post vi parler� di come abbiamo gestito la parte delle chiamate HTTP che ha richiesto molto lavoro per creare una soluzione completa.

Tags: Architettura, Windows Phone, Windows Phone 7, Windows Presentation Foundation, XAML

Continua a leggere Take Me Back e l'architettura.

Progress di una chiamata Silverlight ad un servizio

Cristian "Ricciolo" Civera — Wed, 09 Jun 2010 16:13:00 GMT

Ormai si sa, Silverlight come unico strumento di accesso ad informazioni remote, permette di usare i servizi, siano essi sviluppati lato server in asmx, WCF o altre tecnologie. Non � propriamente l'unica perch� possiamo effettuare chiamate HTTP generiche e tramite REST/POX ottenere sottoforma di Json e XML i dati. Ad ogni modo i servizi usano uno standard e sono molto comodi e facili da utilizzare, grazie alla generazione automatica del proxy.

Durante un corso mi � stato per� chiesto se possiamo conoscere lo stato di avanzamento di una chiamata ad un servizio. Partiamo dal presupposto che un servizio non dovrebbe mai restituire una quantit� notevole di dati per due principali motivi:

� una chiamata HTTP, se qualcosa si interrompe siamo costretti a rieffettuare la chiamata e riottenere l'intera risposta;
� probabile che tutti questi dati non servano per intero all'utente fin dall'inizio e una buona politica di frammentazione di download delle informazioni � la strada ideale.

Ad ogni modo, un servizio che restituisce 1/5MB pu� essere accettabile e l'ideale sarebbe fornire lo stato di avanzamento all'utente. Per capire come conoscere lo stato di avanzamento dobbiamo prima di tutto sapere che sia Silverlight, lato client, che WCF, lato server, bufferizzano la richiesta e la risposta. Questo significa che entrambi preparano il messaggio SOAP, lo serializzano e lo mandano in risposta, o viceversa, leggono i byte della richiesta/risposta e solo quando interamente caricata preparano il messaggio e lo interpretano.

Poich� a noi interessa l'aspetto Silverlight dobbiamo prima di tutto modificare nel file ServiceReferences.ClientConfig l'attributo transferMode:

<basichttpbinding>
  <binding transfermode="StreamedResponse">
</binding>

In questo modo il binding HTTP di Silverlight comincer� a leggere la risposta pian piano che i byte giungono dal server. Questo per� non basta perch� non abbiamo cognizione dell'avanzamento della lettura della risposta. In Silverlight 4.0 possiamo scrivere behavior, binding e inserire message inspector, tutte cose ereditate da WCF del .NET Framework, ma non possiamo riscrivere parzialmente il basicHttpBinding e in generale HttpChannelFactory. Fortunatamente questo oggetto sfrutta al suo interno, per effettuare fisicamente la chiamata HTTP, la classe HttpWebRequest.

Per conoscere lo stato di avanzamento possiamo quindi personalizzare il modo in cui l'HttpWebRequest viene creato. Per farlo nel .NET Framework, ma anche in Silverlight, abbiamo a disposizione il metodo statico WebRequest.RegisterPrefix per indicare, in base allo schema, quale IWebRequestCreate utilizzare. Normalmente possiamo scegliere tra WebRequestCreator.BrowserHttp e WebRequestCreator.ClientHttp. Il primo sfrutta lo stesso motore del browser e contiene quindi i cookie del dominio e permette al browser di leggere la risposta, mentre il secondo scavalca il browser e permette di effettuare chiamate HTTP in liber�.

L'idea � quindi di creare un IWebRequestCreate e relativi HttpWebRequest, HttpWebResponse e Stream personalizzati che mi permettano di sapere a che punto si trova la lettura dello Stream. Quando infatti impostiamo il transferMode a streamed viene impostato sull'oggetto HttpWebRequest la propriet� AllowReadStreamBuffering a false, permettendo la lettura dello Stream mentre riceviamo i byte.

Per andare al sodo, qua trovate un'applicazione di esempio. Prima di tutto registro il mio creator personalizzato:

WebRequest.RegisterPrefix("http://", AdvancedWebRequestCreator.Default);

Tramite esso posso poi intercettare l'evento che mi notifica lo stato di avanzamento di una chiamata.

AdvancedWebRequestCreator.Default.UriProgressChanged += new EventHandler<UriProgressChangedEventArgs>(Default_UriProgressChanged);

Nell'evento so l'URI del servizio che sto chiamando, la percentuale, i byte scaricati e totali. Ho anche aggiunto una propriet� per indicare, per ogni URI, quale creator utilizzare, utile per quando usiamo i due client (http e browser) in modo misto.

AdvancedWebRequestCreator.Default.Mappings.Add(new UriCreateMapping(new Uri("http://sito.it"), WebRequestCreator.ClientHttp));

Per il resto basta chiamare il servizio come normalmente facciamo. Un'ultima nota per quanto riguarda WCF lato server: il transferMode dev'essere obbligatoriamente su buffered altrimenti la risposta non conterr� il ContentLength ed � impossibile per noi indicare lo stato.

Tags: .NET Framework 3.0, Silverlight, Web Service, Windows Communication Foundation, XAML

Continua a leggere Progress di una chiamata Silverlight ad un servizio.

Inside ModelVirtualCasting #5: i servizi

Cristian "Ricciolo" Civera — Mon, 07 Jun 2010 15:58:00 GMT

Quarto post della serie sugli internals dell'applicazione che abbiamo mostrato nel corso della Real Code Conference 4.0 lo scorso 25 Maggio 2010 i cui sorgenti sono disponibili su Codeplex:

I servizi sono uno strato presente sin dalla prima versione di MVC e svolgono un ruolo cruciale nel nostro progetto: rappresentano il punto di accesso alle informazioni e sono l'intermediario verso il repository. Durante il RCC ho voluto quindi mostrare come, una volta preparato l'accesso al database tramite Entity Framework e modellato l'object model, sia semplice con Windows Communication Foundation esporre in molteplici modi le informazioni verso il web o verso applicativi di nostra realizzazione.

Il nostro progetto prevede infatti:

un'applicazione Silverlight per la consultazione delle modelle;
un'applicazione WPF per la gestione delle modelle e nello specifico delle foto/video;
alcune pagine AJAX per la consultazione delle modelle tramite REST;
l'esposizione delle informazioni anche mediante Open Data Protocol (OData);
la generazione di un feed RSS per le notizie.

Nei progetti ASPItalia.ModelVirtualCasting.WCF.Services e ASPItalia.ModelVirtualCasting.WCF.Contracts possiamo quindi trovare la definizione dei servizi e la loro implementazione. I contratti sono dei DTO, cio� un sottoinsieme delle informazioni relative alle modelle e supportano il versioning. In questo modo durante le fasi di preparazione, abbiamo potuto lavorare in modo separato, senza dover aspettare che l'OO e il repository fossero pronti ed inoltre evitiamo di rompere la compatibilit� con consumer che utilizzano contratti vecchi.

I servizi sono esposti con binding basicHttpBinding (per SOAP, utilizzato dai due applicativi) e webHttpBinding (per le pagine AJAX). Il servizio � raggiungibile tramite il file ModelsManager.svc o tramite gli alias /webAPI, /feed e /odata che ho definito nel global.asax. Il servizio principale � addobbato di attribute per sfruttare REST o sfruttare anche le nuove caratteristiche di WCF 4.0. Nel web.config � infatti abilitato l'auto help page (raggiungibile all'indirizzo /webAPI/help).

L'uri odata espone un servizio WCF Data Service che si appoggia ad una sorgente personalizzata che, sempre tramite DTO, permette di accedere alle informazioni secondo lo standard. Di fatto ho messo in pratica lo script #173. Sull'uri feed risponde invece il SyndicationService, il quale restituire le news delle modelle.

Insomma, ho incluso WCF in tutte le salse (almeno quelle web) per dimostrare poi quanto in realt� � semplice. Seguir� un altro post per mostrare come con Javascript, le ASP.NET AJAX e/o jQuery possiamo interrogare questi servizi.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, .NET Framework 4.0, Model Virtual Casting, WCF Data Services, Windows Communication Foundation

Continua a leggere Inside ModelVirtualCasting #5: i servizi.

Quando usare gli optional parameter di C# 4

Cristian "Ricciolo" Civera — Wed, 28 Apr 2010 18:14:00 GMT

Ormai si sa: tra le novit� di C# 4 vi � la possibilit� di usare parametri opzionali nei metodi. Non voglio parlare di come si dichiarano metodi e come si usano, perch� gi� ne parla Andrea in questo articolo. Voglio piuttosto soffermarmi sull'utilit� e l'ambito di utilizzo.

Partiamo da un semplice esempio:

public void DoSomething(string s = "")
{
  // Faccio qualcosa
}

Compilandolo possiamo dare un'occhiata all'assembly risultante e analizzare il metodo DoSomething, il cui IL in realt� � identico al passato. Nessuna nuova funzionalit� dell'IL quindi, ma solo due attributi applicati ad ogni parametro: Optional e DefaultParameterValue. Entrambi sono contenuti nel namespace System.Runtime.InteropServices e sono solamente informazioni utilizzate dal compilatore. Di fatto possiamo infatti dichiarare il metodo in questo modo:

public void DoSomething([Optional, DefaultParameterValue("")] string s)
{
}

La prima nota interessante riguarda Visual Basic. Fin dalla sua prima versione (per .NET) ha sempre supportato gli optional parameter e il compilatore produce tali attributi. Questo quindi conferma la convergenza dei due linguaggi ed �, una volta tanto, un punto a favore di Visual Basic.

Passiamo quindi all'utilizzo del metodo. Gli attributi vengono letti da Visual Studio e tramite l'intellisense ci viene mostrato il parametro opzionale e il suo valore predefinito. Chiamiamo il metodo senza indicare il parametro:

DoSomething();

Compiliamo e guardando l'assembly possiamo notare che in realt� la chiamata a DoSomething � completa, con tanto di stringa vuota:

DoSomething("");

Questo significa che contrariamente a quanto abbiamo � pensato quando abbiam visto gli optional parameter, non si sostituiscono agli overload dei metodi. Poniamo infatti di avere un assembly A con un metodo che dispone di parametri opzionali. L'assembly B lo referenzia e con la compilazione chiama il metodo con il valore X. In un successivo momento cambiamo l'assembly A e il valore opzionale in Y. L'assembly B continuer� ad usare il valore X. Questo "difetto" non c'� con gli overload dei metodi ed � il medesimo che hanno le costanti nei confronti dei membri statici.

Potremmo dire che "basta saperlo", ma non � cos� semplice. Meglio evitare certi pericoli e difatti, da quanto mi risulta, gli optional parameter non sono CLS compliant. Non a caso nel .NET Framework 4.0 gli optional paramenter non sono usati e gli overload persistono. Ma allora quando ha senso usarli? Per i membri privati, dove sappiamo che ricompilando i valori comunque cambiano, ma personalmente non mi piace: gli attributi messi per queste cose non mi piacciono.

Il vero motivo per cui esistono � per supportare COM. Insieme a dynamic, gli optional parameter semplificano notevolmente l'interop con componenti farciti di parametri opzionali, primi tra tutti le PIA di Office. Prima di C# 4, chiamare COM era davvero un delirio.

Tags: .NET Framework, .NET Framework 4.0

Continua a leggere Quando usare gli optional parameter di C# 4.

Routing alla massima potenza

Cristian "Ricciolo" Civera — Wed, 07 Apr 2010 06:24:00 GMT

Il routing � quella funzionalit� introdotta con ASP.NET 3.5 SP1, grazie ad una necessit� di ASP.NET MVC, che ci permette creare URI decisamente pi� SEO. Nel nostro libro su ASP.NET 4.0 ne parlo abbondantemente e la sua forza risiede nella sua indipendenza dall'handler che deve processare la richiesta. Non dobbiamo infatti pensare che sia una caratteristica limitata ad ASP.NET MVC ne tanto meno ad ASP.NET WebForm. A tal proposito � curioso come si tende a separare le due tecnologie quando una ViewPage (classe base delle view di MVC) sia comunque una Page (classe base delle webform) che da essa erediti tutte le caratteristiche in parte poi non utilizzate, ma che in ogni modo lo rende un handler ASP.NET sottoposto alla medesima pipeline di esecuzione di una richiesta.

Volendo allargare ancora di pi� la visione, ASP.NET si presta anche per altri motori, come per esempio i servizi WCF. Se ne sviluppiamo uno, possiamo ospitarlo all'interno di IIS tramite i file .svc, ma questo presenta, soprattutto per le WebAPI esposte tramite REST, un brutto difetto. Un WCF Data Services viene infatti raggiungo con un URI simile a http://localhost:41874/WcfDataService1.svc/MiaOperazione di difficile comprensione e poco SEO.

 Public Class Global_asax
    Inherits System.Web.HttpApplication

    Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)

        RouteTable.Routes.Add(New ServiceRoute(&quot;products&quot;, New DataServiceHostFactory(), GetType(WcfDataService1)))

    End Sub

Con queste poche righe possiamo richiamare il servizio con l'URI http://localhost:41874/Products/MiaOperazione. Molto meglio :-)

Tags: .NET Framework, .NET Framework 3.5, .NET Framework 4.0, ASP.NET, ASP.NET 4.0, ASP.NET 4.0 Guida completa, ASP.NET MVC, SEO, WCF Data Services

Continua a leggere Routing alla massima potenza.

Open Data Protocol e WCF Data Services

Cristian "Ricciolo" Civera — Fri, 02 Apr 2010 13:59:00 GMT

E' un po' che non scrivo nel blog e me ne scuso. In generale cerco sempre di dare qualcosa di pi� rispetto ad un semplice link e sebbene ho scritto poco in questo blog, potete trovare il frutto delle mie esperienze negli script che settimanalmente sforno. Spero che questo sia l'inizio di una serie infinita di post :-)

Dopo questa premessa vorrei porre l'attenzione su un nuovo modo di rendere fruibili le informazioni mediante HTTP. Microsoft sta infatti spingendo molto sull'Open Data Protocol e perfino al MIX ha mostrato una demo che mostrava come tramite REST si possa interrogare il database di netflix. Con OData si vuole spingere anche le altre piattoforme ad implementare un modo univoco per interrogare database tramite HTTP e ottenere risposte in formato AtomPub o Json. Ci sono gi� librerie per PHP, Java e ObjectC e di fatto stanno rendendo standard quelli che una volta erano conosciuti con il nome di ADO.NET Data Services e poi ribattezzati WCF Data Services, perch� di fatto sono dei servizi WCF preconfezionati che permettono le classiche operazioni CRUD sui dati. Li abbiamo trattati e li tratteremo ancora in WinFXItalia.com e SilverlighItalia.com, e potete trovare materiale a riguardo qua.

Le specifiche ora sono giunte alla versione 2 e in esse sono cambiati alcuni modi di formattazione delle risposte, soprattutto per i tipi complessi. Tale versione � implementata dal .NET Framework 4.0 e quindi dobbiamo aspettare ancora un pochetto, soprattutto perch� la versione 3.5 presenta molteplici known issue.

Parecchio tempo fa avevo manifestato le mie perplessit� su questa moda REST/POX e presentato i limiti di queste tecnologie che sono stati in parte colmati. Ad esempio non mi � mai piaciuto che io mi debba leggere un documento che mi spieghi come � fatto l'XML che ottengo in risposta o quali sono gli URI da chiamare. Guarda caso OData definisce questi aspetti e li uniforma. Inoltre se abbiamo un servizio OData possiamo invocare l'URI http://localhost:41874/WcfDataService1.svc/$metadata e ottenere in risposta un XML che definisce il container e le entit�. Questo ci permette di aprire Visual Studio e tramite 'add service reference' referenziare un servizio OData. Quello che otteniamo � un wrapper che attraverso IQueryable ci permette di creare query e tradurle automaticamente in URI, come da queste specifiche.

Tutto questo � molto bello, ma sa di gi� visto e sembra l'ennesimo tentativo di cercare di spingere all'uso di uno standard. I metadati di OData hanno una grossa similitudine con il WSDL e con tutte le altre specifiche WS-* utilizzate per i servizi basati su SOAP. La sensazione � che si voglia semplificare le specifiche e il protocollo per favorirne l'adozione, ma cos� facendo ovviamente si lasciano irrisolti molte cose. OData non � infatti paragonabile alle funzionalit� offerte da WS-* in termini di sicurezza, gestione degli errori e delle transazioni, routing e indipendenza dal mezzo.

Quindi semplicemente le due tecnologie (OData, WS-*) non sono in concorrenza, ma semplicemente coprono scopi diversi. Per questo motivo nel capitolo del libro su VB e C# che ho dedicato a WCF, ho affrontato questa tecnologia in modo da analizzare come questa si presta sia per servizi classici SOAP, sia per servizi OData e a quest'ultimi ho dedicato un'ampia finestra.

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, .NET Framework 4.0, C# 4 Guida completa, Visual Basic 2010 Guida completa, WCF Data Services, Windows Communication Foundation

Continua a leggere Open Data Protocol e WCF Data Services.

MetadataDiffViewer: aggiornato al .NET Framework 4.0, Silverlight 4.0 e Sharepoint 2010

Cristian "Ricciolo" Civera — Thu, 07 Jan 2010 12:58:00 GMT

Come promisi parecchio tempo fa, sto mantenendo il MetadataDiffViewer, il tool realizzato in Silverlight che permette di visualizzare le differenze tra le versioni dei framework.

Ho aggiornato prima di tutto il metodo di download dei metadati rendendolo pi� veloce e richiedendo meno spazio nello storage. Ora richiede la versione 3.0 di Silverlight e supporta il mouse wheel.

Anche i metadati sono stati aggiornati per supportare il .NET Framework 4.0 Beta 2, Silverlight 4.0 Beta 1 e Sharepoint 2010, comparati con le relative precedenti versioni.

Spero possa esservi utile per i vostri studi.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, .NET Framework 4.0, SharePoint

Continua a leggere MetadataDiffViewer: aggiornato al .NET Framework 4.0, Silverlight 4.0 e Sharepoint 2010.

Silverlight - Real time audio peak meter

Cristian "Ricciolo" Civera — Sun, 31 May 2009 09:14:00 GMT

In un post precedente ho mostrato di come si pu� realizzare un misuratore di picchi per l'audio di un MediaElement precalcolandoli con un'applicazione console. Ovviamente questa non � la prassi normale di tutti i lettori normali, dove il calcolo della FFT applicata ai samples avviene in real time, man mano che questi vengono renderizzati sulla periferica audio.

Da Silverlight 2.0 sull'oggetto MediaElement � presente un metodo SetSource che accetta uno Stream oppure un'oggetto MediaStreamSource. Questa classe ha dei metodi che MediaElement chiama, come OpenMediaAsync, GetSampleAsync, SeekAsync per chiederci di aprire la sorgente, di restituirgli gruppi di samples o di posizionarci ad uno specifico timestamp. Con i metodi ReportOpenMediaCompleted, ReportGetSampleCompleted e ReportSeekCompleted non si fa altro che notificargli l'avvenuta operazione e ciclicamente mandargli pacchetti audio/video.

La brutta notizia � che i samples audio e video devono essere compressi (MP4, WMV) e quindi quello che noi possiamo fare � solo fare da tramite per fonire tracce audio e video con i protocolli che vogliamo: RTP, UPNP, streaming custom. Questa � una brutta notizia perch� per applicare la FFT occorre avere i samples grezzi, gi� decodificati. L'oggetto MediaElement non permette di caricare file WAV direttamente, ma il MediaStreamSouce permette invece di passare anche i samples raw, che il file WAV appunto contiene. Sebbene si potrebbe scrivere un decoder MP3, non sono cos� pazzo da farlo :-), perci� ho scelto di creare un file WavMediaStreamSource che carica tramite WebRequest un file wav e legge l'header per conoscere il numero di canali, i samples al secondo (solitamente 44100) e i bit (8/16). L'implementazione poi non fa altro che rigirare i byte al MediaElement.

Ho portato poi l'algoritmo FFT e di calcolo dei picchi sulla mia libreria Silverlight e diviso il controllo del post precedente in due parti: DataAudioPeakMeter e SamplesAudioPeakMeter. Il primo lavora con il file dat precalcolato e funziona con tutti i formati supportati da SL. Il secondo lavora solo con i file WAV, ma funziona in real time. Entrambi poi fanno uso della BarVisualization per l'animazione.

L'utilizzo � piuttosto semplice:

<MediaElement AutoPlay="False"
              x:Name="media" />

<!-- Visualization -->
<a:SamplesAudioPeakMeter x:Name="sa">
    <a:BarVisualization BarSegmentHeight="4"
        BarMargin="1"
        BarSegmentMargin="1"
        StrokeBrush="Yellow"
        StrokeThickness="1">
        <a:BarVisualization.BarBrush>
            <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
                <GradientStop Offset="1"
                              Color="Black" />
                <GradientStop Offset="0"
                              Color="Blue" />

            </LinearGradientBrush>
        </a:BarVisualization.BarBrush>
    </a:BarVisualization>
</a:SamplesAudioPeakMeter>

Da codice poi dobbiamo legare la sorgente wav sia al MediaElement che al SamplesAudioPeakMeter:

WavMediaStreamSource source = new WavMediaStreamSource(new Uri("test1.wav", UriKind.RelativeOrAbsolute));
source.Loop = true;

// Binding Source -> Visualization
sa.SetSource(source);
// Binding Source -> MediaElement
media.SetSource(source);

Ed ecco il risultato:

Ovviamente i file wav sono di grandi dimensioni quindi questa tecnica � adatta per file di piccola di dimensione sulla quale fare loop, ma meglio di niente :-). Poi speriamo che magari nella RTM di Silverlight 3.0 ci sia la possibilit� di accedere ai samples gi� decodificati.

Infine le performance: escludendo l'animazione sono rimasto piuttosto colpito. La mia CPU resta su un 2% per calcolare FFT e picchi. Includendo l'animazione si arriva poi ad un 25/30%, ma va considerato che SL tenta sempre di andare al massimo di frame rate per l'esecuzione delle animazioni.
Presto metter� i sorgenti: promesso!

Tags: Silverlight, Silverlight - animazioni, Silverlight 2.0, XAML

Continua a leggere Silverlight - Real time audio peak meter .

Salvare immagini Bitmap con Silverlight 3.0

Cristian "Ricciolo" Civera — Fri, 29 May 2009 17:56:00 GMT

In Silverlight 3.0 � stato aggiunta la possibilit� di salvare file in locale attraverso la SaveFileDialog. Per motivi di sicurezza, questa pu� essere visualizzata solo all'interno di un evento scatenato dall'utente (pressione del pulsante, ecc) mentre attraverso OpenFile � possibile poi aprire uno Stream per la scrittura sulla quale � possibile scrivere qualsiasi cosa.

In una discussione con Marco ci � venuto il dubbio se si poteva salvare immagini in locale, ma purtroppo la cosa non � molto semplice da raggiungere. In SL infatti non ci sono API per effettuare encoding ed decoding di immagini ad eccezione del passare uno Stream da visualizzare. Inoltre con WriteableBitmap � stata aggiunta la possibilit� di caricare uno Stream o di renderizzare un UIElement su un'immagine, ma poi non � possibile accedere ai byte. Insomma, se si ha un'immagine gi� codificata in JPEG/PNG basta semplicemente travasare lo Stream sorgente verso il file locale, altrimenti se si ha solo i byte grezzi dell'immagine occorre scriversi il motore di encoding e di creazione del contenitore.

Per fortuna c'� il buon vecchio file BMP, la cui definizione si pu� trovare qui, che � abbastanza semplice da creare e a parte dover accodare i byte dell'immagine dal basso verso l'altro, non necessita di algoritmi di compressione. Ovviamente il file risultante � di grandi dimensioni, ma non dev'essere trasportato in rete, ma bens� salvato direttamente in locale. Ho scritto quindi un BitmapEncoder e un BitmapFrame per salvare un'immagine in BMP, lo trovate completo di sorgente qua. L'esempio allegato genera un'immagine con un algoritmo e la mostra anche attraverso un WriteableBitmap.

Purtroppo non serve a tantissimo, perch� attualmente la WriteableBitmap non permette di accedere ai pixel e quindi non � possibile salvare screenshot effettuati sugli elementi. Potenzialmente si pu� creare qualsiasi file, ma ovviamente non � semplice doversi riscrivere librerie di creazione di file, non potendosi appoggiare a oggetti COM.

Tags: Silverlight, XAML, Silverlight 3.0

Continua a leggere Salvare immagini Bitmap con Silverlight 3.0.

.NET Framework 4.0 beta 1: Tuple

Cristian "Ricciolo" Civera — Wed, 27 May 2009 04:00:00 GMT

Altro post per un'altra novit� del .NET Framework 4.0: le classi Tuple. In pratica sono delle classi generiche con tanti argomenti generici quanti sono le relative propriet� che esse espongono.

Per esempio Tuple<T1, T2> ha una propriet� Item1 di tipo T1 e una propriet� Item2 di tipo T2. Ci vengono molto comode per quelle volte che nei nostri algoritmi, per velocizzare la scrittura del codice (o per pigrizia :-) ), abbiamo bisogno di una classe che faccia da repository dei valori. Inoltre la loro caratteristica � di implementare GetHashCode, Equals e l'interfaccia IComparable, IStructuralEquatable (nuova in .NET 4.0) e IStructuralComparable (nuova in .NET 4.0) in modo che a parit� dei valori, due istanze di Tuple diverse risultino uguali. Si comportano quindi come un valore atomico e sono l'ideale per essere utilizzate come chiavi per dictionary o per hash set.

Per capirci quindi:

var t = Tuple.Create<Int32, String>(2, "ciao");
var t2 = Tuple.Create<Int32, String>(2, "ciao");

Console.WriteLine(t.Item2);
Console.WriteLine("Reference equals: {0}", Object.ReferenceEquals(t, t2));
Console.WriteLine("Equals: {0}", t.Equals(t2));

stampa a video:

ciao
Reference equals: False
Equals: True

In effetti c'� una forte somiglianza agli anonymous type sebbene quest'ultimi sono generati dal compilatore e hanno propriet� dal nome che vogliamo. In comune hanno infatti che due istanze diverse, ma con identici valori, risultano uguali se comparati tra loro. Non implementano per� IStructuralEquatable, ma non credo che questo sia un problema. Se necessitiamo di lavorare a livello d'interfaccia allora tanto vale restituire una tuple nelle nostre query.

Tags: .NET Framework, .NET Framework 4.0

Continua a leggere .NET Framework 4.0 beta 1: Tuple.