blogs.ASPItalia.com

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.

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.

.NET Framework 4.0 beta 1: Windows Communication Foundation

Cristian "Ricciolo" Civera — Mon, 18 May 2009 14:00:00 GMT

Vista l'imminente uscita del .NET Framework 4.0 beta 1 vediamo un po' tra le numerose novit�, quali sono quelle che riguardano WCF. Nonostate fino ad ora non � stata resa pubblica una build completa si conoscono gi� le principali nuove caratteristiche.

Si parte dai miglioramenti di prestazioni del DataContractSerializer, motore principale per la serializzazione degli oggetti e un nuovo DataContractResolver che permette di personalizzare la risoluzione dei tipi. La configurazione, punto dolente della prima versione, � stata semplificata. Ora � possibile definire un servizio e/o un behavior con name vuoto e si ottiene una configurazione predefinita per tutti i servizi dell'hosting. I file svc sono poi auto configuranti e ci� significa che viene creato automaticamente un endpoint basandosi sulle configurazioni predefinite dei servizi HTTP.

Sono disponibili poi nuovi binding e nuovi canali tra i quali la possibilit� di fare HTTP polling duplex (usato da Silverlight), di esporre un servizio tramite UDP, un nuovo sistema di claim basato su Geneva, nome in codice del nuovo framework per l'autenticazione e gestione dell'identit�. WCF 4.0 aderisce alle specifiche Basic Profile 1.2 che garantiscono una migliore interoperabilit� tra piattaforme diverse ed implementa inoltre WS-Discovery e il routing. Il primo permette ad un servizio di annunciarsi attraverso endpoint conosciuti che i possibili client possono individuare ed andare a consumare. Con il servizio di routing � invece possibile porre uno strato intermedio che dirotti le richieste verso gli endpoint effettivi a seconda dei carichi od in base a regole XPath applicate sul messaggio.

WCF inoltre si accopia con Windows Workflow Foundation diventando praticamente un solo framework. Questo perch� dall'idea di Workflow Services, introdotti con il service pack 1 del .NET Framework 3.5, si � passati ad una forte cooperazione ed integrazione tra le tue tecnologie. Partecipano allo stesso sistema di tracing e di tracking, di gestione degli errori, di transazione e sfruttando WAS e tutti gli strumenti aggiuntivi messi a disposizione per IIS7, raccolti sotto il nome di Dublin, permettono di esporre workflow attraverso servizi e di gestire e monitorare i workflow facilitando moltissimo la creazione di servizi duraturi nel tempo e scalabili.

Maggiori informazioni e le informazioni per il download sono disponibili nel nostro mini-sito dedicato al .NET Framework 4.0.

Tags: .NET Framework 3.0, .NET Framework 4.0, Windows Communication Foundation, Windows Workflow Foundation, .NET Framework

Continua a leggere .NET Framework 4.0 beta 1: Windows Communication Foundation.

Parallelizzare in Silverlight 2.0

Cristian "Ricciolo" Civera — Tue, 21 Apr 2009 05:27:00 GMT

Durante lo sviluppo di MetadataDiffViewer ho dovuto fare i conti con la grande quantit� di informazioni da dover processare e dover trovare un modo di rendere l'interfaccia la pi� utilizzabile possibile. Per prima cosa ho optato per preparare una struttura di assembly/module/type/member tutta in lazy loading, in questo modo solo nell'espandere un assembly vengono caricati i moduli, solo espandendo un modulo vengono caricati i tipi ecc. LINQ a questo scopo � fantastico perch� lavorando con IEnumerable si pu� parserizzare, incrociare, ordinare, ma elaborare il tutto solo quando viene effettivamente consumato.

Questo comporta per� un difetto perch� non mi consente di mostrare preventivamente quali assembly sono cambiati. Ho optato quindi per eseguire in un thread in background e ciclare per la struttura ad oggetti; appena trova un elemento cambiato, l'intero assembly � cambiato e perci� evito di proseguire. Questa operazione era comunque lunga e la cosa meno piacevole era vedere la cpu che lavorava solo al 50%, essendo un dual core.

Mi son scritto quindi un piccolo extension method, specifico per la mia esigenza, per parallelizzare un'operazione basata su sorgenti LINQ. Il primo problema � determinare quanti core abbiamo a disposizione, ma non potendo accedere all'OS ho ripiegato sul fatto che il thread pool in SL 2.0 ha 250 thread per core e questo numero non si pu� cambiare. Perci� ho creato una semplice propriet�:

private const int DefaultThreadsPerCpu = 250;

public static int CpuNumber {
    get {
        int wt; int cpt;
        ThreadPool.GetMaxThreads(out wt, out cpt);
        return Math.Max(1, wt / DefaultThreadsPerCpu);
    }
}

L'extension method che ho poi definito accetta una sorgente dati sul quale ciclare e un delegate ad una funzione che elabora ogni item ed eventualmente restituisce un risultato:

public static IEnumerable<tresult> ForEach<IEnumerable<T>, TItem, TResult>
                                   (this IEnumerable<T> source, Func<TItem, TResult> process)
{
{

Per prima cosa ho ripartito la sorgente in n parti, quante sono le cpu, incrociando gli item. Ad esempio su due core al primo vanno l'item 1,3,5.., al secondo vanno 2,4,6.

int cpuNumber = CpuNumber;

// Elementi da processare per ogni cpu
IEnumerable<TItem>[] items = new IEnumerable<TItem>[cpuNumber];
// Semafori di notifica per ogni cpu
ManualResetEvent[] events = new ManualResetEvent[cpuNumber];
// Risultati ottenuti per ogni cpu
IList<TResult>[] results = new IList<TResult>[cpuNumber];

int itemsPerCpu = (int)Math.Ceiling(source.Count() / (double)cpuNumber);

for (int x = 0; x < items.Length; x++)
{
    items[x] = new TItem[itemsPerCpu];
    int cpu = x;
    // Ripartizione incrociata
    items[x] = source.Where((item, index) => (index + cpu) % cpuNumber == 0);
}

L'uso della variabile interna cpu che semplicemente ricopia x � fondamentale perch� all'atto del consumo di items[] x sarebbe sempre all'ultimo valore. Usando LINQ occorre infatti ricordarsi che l'elaborazione avviene a posteriori, a meno non si chiami un ToList/ToArray.

A questo punto avvio i thread e aspetto tramite un WaitHandle che questi abbiamo finito di lavorare:

for (int x = 0; x < items.Length; x++)
{
    // Semaforo di notifica al thread che ha lanciato ForEach
    events[x] = new ManualResetEvent(false);
    results[x] = new List<TResult>(itemsPerCpu);
    Thread t = new Thread(delegate(object i)
    {
        int index = (int)i;

        foreach (TItem item in items[index])
            results[index].Add(process(item));

        events[index].Set();
    });
    t.Start(x);
}

WaitHandle.WaitAll(events);

I risultati sono un List che poi vengono restituiti, in questo caso non nello stesso ordine della sorgente. Tutto questo per la mia esigenza, ma le variabili possono essere tante, in funzione della sorgente (pu� non essere possibile dividere il carico in quel modo), o del risultato (certi risultati dipendono dai risultati degli altri thread), ma � un inizio. L'uso poi � molto semplice:

var r = from n in Enumerable.Range(1, 1000)
     select "Ciao " + n;
int l = r.ForEach(s => s.Length).Sum();

Tags: .NET Framework 3.5, LINQ, Silverlight, Silverlight 2.0, XAML

Continua a leggere Parallelizzare in Silverlight 2.0.

Silverlight: performance dell'isolated storage

Cristian "Ricciolo" Civera — Thu, 16 Apr 2009 17:03:00 GMT

Durante lo sviluppo del MetadataDiffViewer ho dovuto ricorrere all'uso dell'Isolated Storage per salvare i metadati in locale e poterli prelevare da disco invece che da remoto. Ho notato per� che le performance, rispetto allo scaricare da un webserver in locale, erano peggiori ed era imputabile a:

la chiamata a IsolatedStorageFile.GetUserStoreForApplication/Site: � molto costosa, aprendo lo storage una sola volta, dall'inizio alla fine ho guadagnato un 40% di performance;
la lettura dello stream attraverso IsolatedStorageFileStream: � un pi� lenta rispetto ad uno stream in memoria nelle operazioni di accesso randomico. Questo � ovvio visto che va su disco, ma non pensavo cos� tanto. Precaricando il tutto in un MemoryStream e parserizzando poi l'XML con XDocument.Load in un'attivit�, ho guadagnato 3 secondi su 14 e non � poco.

Insomma, occhio a come lo usate.

Tags: Silverlight, Silverlight 2.0, Silverlight 3.0, XAML

Continua a leggere Silverlight: performance dell'isolated storage.

MetadataDiffViewer: differenze tra i framework

Cristian "Ricciolo" Civera — Wed, 15 Apr 2009 16:56:00 GMT

MetadataDiffViewer � un'applicazione in Silverlight che mostra le differenze in termini di assembly/module/type/member tra una versione del .NET Framework e l'altra. Semplicemente mostra alcune informazioni precalcolate per conoscere nel dettaglio cosa c'� di nuovo in una nuova versione.

Ecco uno screenshot:

Lo potete provare qua.

Non so voi, ma mi d� fastidio essermi perso un nuovo membro. Con questo tool non ci sono pi� scuse :-)

Come funziona?

Ho innanzitutto creato un addin per Reflector cos� da poter esportare i metadati pubblici degli assembly. La reflection classica non permette di caricare pi� versione del framework e in un'ottica continua nel tempo ho deciso di esportare i metadati e tenerli sempre pronti. Una console application poi li compara e crea un file di differenze. I metadati e le differenze sono file XML di discreta dimensione perci�, per non riscaricare tutte le informazioni ogni volta, ho deciso di salvare le informazioni nell'isolated storage. Per tenersi il tutto servono circa 60MB (tranquilli, sono zippati quando si scaricano).

I framework comparati che sono a disposizione sono:

Silverlight 2.0 -> Silverlight 3.0
.NET Framework 1.1 -> .NET Framework 2.0
.NET Framework 2.0 -> .NET Framework 3.5

Se avete problemi o consigli, scrivetemi.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Silverlight 3.0, XAML

Continua a leggere MetadataDiffViewer: differenze tra i framework.

Documentazione MSDN e versioni del .NET Framework

Cristian "Ricciolo" Civera — Wed, 15 Apr 2009 13:23:00 GMT

In questo post qualcosa di poco tecnologico, ma che mi segno per me e magari anche voi, per trovare velocemente la documentazione delle classi. Le versioni del framework sono infatti ormai tante: .NET Framework 1.0 - 1.1 - 2.0 - 3.5 e Silverlight 2.0 - 3.0.

Cercando nei motori di ricerca per esempio system.string probabilmente troveremo il link a:

http://msdn.microsoft.com/en-us/library/system.string.aspx

che ci porta alla documentazione riferita alla versione attuale: la 3.5.

Mettendo tra parentesi dopo system.string la versione possiamo per� distinguere e forzatamente guardare uno specifico framework. Per Silverlight 3.0 per esempio �:

http://msdn.microsoft.com/en-us/library/system.string(vs.96).aspx

Ecco un riassunto delle versioni:

vs.71: 1.1
vs.80: 2.0
vs.85: 3.0
vs.90: 3.5
vs.95: SL 2.0
vs.96: SL 3.0

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Silverlight 3.0, XAML

Continua a leggere Documentazione MSDN e versioni del .NET Framework.

Curiosità sui Thread

Cristian "Ricciolo" Civera — Sun, 16 Dec 2007 22:45:00 GMT

In questi giorni grazie ad un esigenza di Rob e Paolo, ho voluto approfondire un aspetto di cui ero gi� a conoscienza, ma del quale non avevo mai fatto test.
Come sapete, un campo dichiarato in una classe pu� teoricamente subire contemporaneamente l'accesso da pi� thread e spesso per rendere la classe thread-safe si ricorrono a tecniche di sincronizzazione per evitare che pi� thread cambino contemporanemante il campo. Non � detto infatti che una singola istruzione di assegnazione sia una singola istruzione di CPU e questo pu� portare ad inaspettati risultati. Questo problema si fa inoltre pi� frequente se si dichiara static (o shared in VB) il campo, condividendo il valore del membro per l'intero AppDomain.

A volte per�, si vuole rendere l'istanza del campo accessible da chiunque purch� dal medesimo thread, togliendo quindi il problema dell'accesso concorrente. L'attributo ThreadStatic permette di marcare un campo e di avere questo comportamento:

[ThreadStatic] <br />private static object threadState;

Questa tecnica viene sfruttata per esempio dall'oggetto Transaction (System.Transactions) per mantenere l'oggetto rappresentante la transazione corrente cosicch� qualsiasi sotto chiamata possa accedere alla transazione corrente semplicemente chiamando Transaction.Current, il tutto isolato per thread (la transazione infatti non � visibile in altri thread, ma ne viene creata un'altra). Lo stesso comportamento, seppure meno comodo, si pu� ottenere usando Thread.AllocateNamedDataSlot, Thread.SetData e Thread.GetData che permettono di allocare per nome uno spazio, di impostarlo e di leggerlo, dove inserire un riferimento ad un oggetto.

La problematica di questo approccio � che nel caso in cui da un thread ne avviamo un altro e si vuole portare con se questi valori "speciali", occorre passarseli tramite argomenti o classi d'appoggio per poi essere copiati sul nuovo thread. Inoltre nel caso del ThreadPool, quell'insieme di thread gi� pronti all'uso, utilizzati quando si chiama la Begin*** di un delegate o si usa ThreadPool.QueueUserWorkItem, il campo statico risulta visibile alle operazioni che verranno prese in carico dal medesimo thread e mai rilasciato (si pensi al Dispose dell'oggetto) se non sovrascritto o impostato a null (il ThreadPool nel .NET 2.0 � composta da 25 Thread per CPU e di 500 IO Thread per CPU, in ASP.NET 2.0 sono 100/100, nel.NET 3.5 sono diventanti 250/500, mentre in ASP.NET 3.5 nella modalit� AutoConfig sono rimasti invariati).

Per risolvere questo problema viene in aiuto la classe CallContext (System.Runtime.Remoting.Messaging) con i metodi LogicalGetData e LogicalSetData per leggere e impostare in base ad una chiave il riferimento ad un oggetto. Il comportamento � simile a ThreadStatic, ma questi valori sono relativi al contesto in cui sono stati impostati. Per capire meglio ho creato questa classe:

public class MyObject : Component <br />{ <br />private readonly string _name; public MyObject(string name) <br />{ <br />    _name = name; <br />} protected override void Dispose(bool disposing) <br />{ <br />    base.Dispose(disposing);     Console.WriteLine(&quot;Disposed {0}&quot;, _name); <br />} public override string ToString() <br />{ <br />    return _name; <br />} <br />}

E' una semplice classe che implementa IDisposable cos� da sapere quando l'oggetto, identificato con un nome, viene distrutto. Poi ho creato una ConsoleApplication che esegue su un thread del pool il controllo di un campo marcato con ThreadStatic, lo valorizza se � nullo e ne stampa il valore. La stessa operazione viene effettuata usando CallContext. Inoltre, attendo la fine dell'esecuzione per assicurarmi che le altre successive operazioni vengono effettuate nuovamente sul medesimo thread ed utilizzo GC.Collect per assicurarmi che gli oggetti, non pi� in uso, vengano distrutti (mi raccomando, in vere applicazioni non si deve chiamare se non in rare eccezioni):

class Program <br />{ [ThreadStatic] <br />private static object threadState; static void Main(string[] args) <br />{ <br />    // Metodo da invocare su un Thread del pool <br />    WaitCallback wc = DoWork;     for (int x = 0; x &lt; 3; x++) <br />    { <br />        // Invoco e attendo che finisca <br />        wc.BeginInvoke(null, EndWork, wc).AsyncWaitHandle.WaitOne();         // Forzo la liberazione degli oggetti <br />        GC.Collect(); <br />        GC.WaitForPendingFinalizers(); <br />    }     // Avvio l'operazione su un nuovo Thread <br />    Thread t = new Thread(DoWork); <br />    t.Start(); <br />    t.Join();     // Forzo la liberazione degli oggetti <br />    GC.Collect(); <br />    GC.WaitForPendingFinalizers();     Console.Read(); <br />} private static void EndWork(IAsyncResult ar) <br />{ <br />    ((WaitCallback)ar.AsyncState).EndInvoke(ar); <br />} const string DataKey = &quot;test&quot;; static void DoWork(object state) <br />{ <br />    Console.WriteLine(&quot;-----------------&quot;); <br />    Console.WriteLine(&quot;Thread {0}&quot;, Thread.CurrentThread.ManagedThreadId);     object t = CallContext.LogicalGetData(DataKey); <br />    if (t == null) <br />    { <br />        t = new MyObject(&quot;LogicalData&quot;); <br />        Console.WriteLine(&quot;LogicalData set&quot;); <br />        CallContext.LogicalSetData(DataKey, t); <br />    } <br />    else <br />        Console.WriteLine(&quot;LogicalData: {0}&quot;, t);     t = threadState; <br />    if (t == null) <br />    { <br />        t = new MyObject(&quot;DataThread&quot;); <br />        threadState = t; <br />        Console.WriteLine(&quot;DataThread set&quot;); <br />    } <br />    else <br />        Console.WriteLine(&quot;DataThread: {0}&quot;, t); <br />    } <br />}

Se lo si esegue, il risultato � il seguente:

----------------- <br />Thread 6 <br />LogicalData set <br />DataThread set <br />----------------- <br />Thread 6 <br />LogicalData set <br />DataThread: DataThread <br />Disposed LogicalData <br />----------------- <br />Thread 6 <br />LogicalData set <br />DataThread: DataThread <br />Disposed LogicalData <br />Disposed LogicalData <br />----------------- <br />Thread 11 <br />LogicalData set <br />DataThread set <br />Disposed DataThread

Come si vede, alla prima esecuzione di DoWork, entrambi i modi di memorizzare MyObject impostano il valore. Alla seconda esecuzione CallContext � di nuovo vuoto e va rivalorizzato, mentre threadState contiene il valore impostato sulla prima esecuzione. Lo stesso avviene anche alla terza esecuzione. E' interessante notare che l'oggetto impostato con CallContext viene effettivamente rilasciato e quindi ucciso dal GC solo all'avviarsi della nuova operazione sul medesimo thread (infatti il primo GC.Collect non ha sortito nessun effetto). Poich� i thread del pool non muoiono mai, DataThread non viene mai eliminato, ad eccezione di quello impostato nel Thread creato manualmente (l'esecuzione � finita e quindi il thread � inutilizzabile).
Tutto questo meccanismo � gestito dalla classe ExecutionContext (System.Threading) che � in grado di catturare, mettere a disposizione o di togliere il contesto e tutti valori ad esso associati. Quando si chiama ThreadPool.QueueUserWorkItem o il Begin*** di un metodo, viene chiamato ExecutionContext.Capture per catturare il contesto e tenerselo pronto quando il thread prende in consegna il delegate da eseguire, ripristinando quindi il contesto chiamando il metodo Run. Se avete mai dovuto creare un vostro ThreadPool, tipo questo, avrete sicuramente avuto a che fare con questa classe. Il bello di questo meccanismo � che se usiamo CallContext per mantenere dei valori ed invochiamo delegate asincroni o creiamo thread, automaticamente il contesto viene passato sull'altro thread condividendolo per la durata dell'operazione. Se nell'esempio precedente quindi si imposta prima di qualsiasi accodamento, l'istruzione CallContext.LogicalSetData(DataKey, new MyObject("test")); si ottiene a console:

Thread 6 <br />LogicalData: test <br />DataThread set <br />----------------- <br />Thread 6 <br />LogicalData: test <br />DataThread: DataThread <br />----------------- <br />Thread 6 <br />LogicalData: test <br />DataThread: DataThread <br />----------------- <br />Thread 11 <br />LogicalData: test <br />DataThread set <br />Disposed DataThread

Si noti che LogicalData su tutti i thread � gi� impostato.

Un'ultimo aspetto riguarda ASP.NET che utilizza anch'esso CallContext.HostContext ogni qualvolta si interroga HttpContext.Current, ma se si usano pagine asincrone con task ecc, i metodi asincroni non dispongono del contesto web e HttpContext.Current ritorna null. Diversamente usando CallContext.LogicalSetData si ha a disposizione l'oggetto anche sui task asincroni ed � quindi l'ideale se dovete mantenere DataContext (LINQ) o Session (NHibernate).

Continua a leggere Curiosità sui Thread.

Perché non usate lo statement using?

Cristian "Ricciolo" Civera — Thu, 06 Dec 2007 11:38:32 GMT

Me lo chiedo perch� la vedo raramente usata nei forum e nel codice che mi capita di guardare e mi domando il perch�, visto che � cos� comoda da usare. Beh il mio consiglio �: qualsiasi oggetto create, se implementa IDisposable, usate sempre la using.
Per i seguenti motivi:

Occorre sempre chiudere risorse unmanaged in modo esplicito e il prima possibile. Se si demanda il lavoro al Garbage Collector il Dispose verr� effettuato sfruttando la Finalize e l'oggetto rester� nell'heap per un giro di GC in pi� e rischiamo inoltre che l'oggetto diventi pi� forte come generation e non venga pi� rimosso;
Anche se l'oggetto non fa uso risorse unmanaged, la Dispose va chiamata lo stesso. Primo perch� non possiamo mai sapere se in una futura versione l'oggetto utilizzer� tali risorse e secondo perch� chiamando Dispose, se la classe � scritta bene, viene chiamato GC.SuppressFinalize(this) cos� da togliere l'oggetto dalla finalization list, il GC lo rimuover� dall'heap e il problema indicato nel primo punto non si verificher�.

Se scriviamo delle nostre classi che fanno uso di risorse unmanaged o di classi che a loro volta ne fanno uso, vi consiglio di ereditare da System.ComponentModel.Component. Implementa gi� il pattern Dispose, con l'interfaccia IDisposable, il metodo Finalize e mettendo a disposizione un metodo virtuale Dispose(bool disposing). Una tipica classe � cos�:

public class MiaClasse : System.ComponentModel.Component 
{ 
    private bool disposed; 
 
    public void MioMetodo() 
    { 
        if (disposed) 
            throw new ObjectDisposedException(base.GetType().Name); 
    } 
 
    protected override void Dispose(bool disposing) 
    { 
        if (disposing) { 
            risorsaunmanaged.Dispose(); 
        } 
        risorsaunmanaged = null; 
 
        this.disposed = true; 
        base.Dispose(disposing); 
    } 
}

L'uso della variabile disposed � "facoltaltiva", ma utile se vogliamo lanciare un eccezione nel caso qualcuno chiami un nostro metodo quando ne ha gi� chiamato il Dispose.
Quindi insomma, usiamo la using che non vi costa e scriviamo le classi nel modo giusto ;-)

Tags: .NET Framework

Continua a leggere Perché non usate lo statement using?.

Interoperabilità .NET con C++ CLI

Cristian "Ricciolo" Civera — Mon, 26 Nov 2007 22:26:00 GMT

In quest'ultimo periodo mi sono addentrato in un mondo che ho sempre ammirato, ma che non ho mai avuto il coraggio di provare: il C++ CLI. Ammirato perch� gi� non ho mai usato C++, figuriamoci un linguaggio pi� evoluto. Per chi non lo sapesse, infatti, C++ CLI � un linguaggio standard ECMA evoluzione delle Managed Extensions C++ e quindi di C++ che permette di mettere in comunicazione il mondo managed .NET con quello unmanaged.

Questo vuol dire che � possibile scrivere DLL che contengano sia codice nativo che lavori con qualsiasi API, sia codice managed che faccia uso poi di classi native. Oltre a ci� � possibile ottenere�il codice di interop in automatico�scrivendo direttamente da�codice managed chiamate a tipi o funzioni native. Cos� facendo si riduce al minimo il marshaling dei tipi e C++ CLI diventa l'ideale per scrivere classi che� permettano di beneficiare dei pregi dei due mondi.
Se avete avuto modo di usare la classe Marshal di System.Runtime.InteropServices sapete delle fatiche che si devono compiere per le strutture ecc e apprezzerete sicuramente questo nuovo strumento.

Beh insomma dopo un po' che ci sto lavorando devo dire che � ganzissimo. Ti senti come Peter Petrelli quando si ritrova tutti quei poteri. Come il personaggio nel senso che come lui non sono capace di usarli e mi fermo fra elementari ostacoli come conversione dei tipi, utilizzo delle librerie e puntatori. Pian piano per� sto prendendo possesso di questi poteri, quindi pi� avanti vi illustrer� cosa sono riuscito a fare.

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

Continua a leggere Interoperabilità .NET con C++ CLI.

Alternativa ai captcha normali

Cristian "Ricciolo" Civera — Fri, 02 Dec 2005 12:53:00 GMT

Qualche tempo fa�Matteo parl� in un suo post dei sistemi anti spam che richiedono capacit� umane per vincere i programmi automatici di spam.

Beh visto che molti algoritmi riescono ad aggirare anche queste protezioni mi son chiesto: cos'� che proprio un software non sa fare?
Ho pensato quindi di popolare un database con delle parole, oggetti singolari e semplici e di prelevare una di queste�randomicamente.
Sfruttando poi il motore di google images prelevo le prime cinque immagini e chiedo all'utente di indicare l'oggetto che vede e intuisce. Considerando che le prime immagini che google propone sono spesso attinenti all'oggetto in questione, che la parola � in italiano e singolare quasi sempre la�si pu� indovinare.

Lo potete provare qua.

Cosa ne pensate? Cavolata? Forse s�, ma la strada secondo me non � sbagliata. Voglio vedere quale algoritmo possa equiparare l'intelligenza umana messa in campo in questo caso. Ovvio che il database � limitato all'italiano, ma si�pu� benissimo nazionalizzare per tutte le lingue, visto che google non soffre di questi problemi.

Continua a leggere Alternativa ai captcha normali.

Compilare per .NET 1.x da Visual Studio 2005?

Cristian "Ricciolo" Civera — Wed, 09 Nov 2005 17:47:00 GMT

A quanto pare la cosa � fattibile. Grazie al fatto che Visual Studio 2005 utilizza msbuild (console per la compilazione compreso nel Framework) � possibile con un nuovo file di building compilare per la versione .NET 1.x.

Le istruzioni le trovate qua.

Non ho ancora provato, ma credo sia una cosa che interessi in molti.

Tags: Visual Studio

Continua a leggere Compilare per .NET 1.x da Visual Studio 2005?.

Libreria per XML

Cristian "Ricciolo" Civera — Thu, 08 Sep 2005 17:37:00 GMT

Il supporto a XML nel Framework.NET � notevole, ma a volte non abbastanza. Per questo vi segnalo questa libreria aggiuntiva "MVP XML" che si sta dimostrando per i miei usi molto utile.
Mi � stata suggerita per necessit� dal mio maestro alias Mr. Xml�ed � sviluppata da un MVP che a parte il nome ambiguo sembra essere molto in gamba.

La libreria ha alcune classi molto utili della quale trovate una spiegazione completa qua:

DynamiContext: utilissimo, vi d� la possibilit� di inserire variabili in query XPath:
IndexingXPathNavigator: XPathNavigator che ottimizza le query XPath in funzioni di chiavi specificabili
XPathNavigatorReader: eredita da XmlTextReader�e accetta come costruttore un XPathNavigator. Utilize se per esempio volete caricare un XmlDocument da un XPathDocument
XPathIteratorReader: come sopra ma accetta un XPathNodeIterator
XmlNodeNavigator: si tratta di un XPathNavigator che accetta come costruttore un XmlNode. Implementa IHasXmlNode e il vantaggio sta nel fatto che a seguito di select o navigazione � sempre possibile risalire all'XmlNode originale
SubtreeXPathNavigator: un XPathNavigator che accetta un XPathNavigator, ma ha il vantaggio di poter rappresentare un documento frammentario. E' utile quando si fanno trasformazioni XSLT. Passare infatti un iterator ad una trasformazione rende visibile l'intero documento ad essa e non magari solo una parte preselezionata.
XmlFirstUpperReader and XmlFirstLowerWriter: si trattano di un XmlTextReader e di un XmlTextWriter che permottono di caricare o salvare tag e attributi con lettera maiuscola o minuscolo. L'esigenza nasce dal fatto che negli schema xsd e in generale in xml si preferisce usare la nomenclatura pascalCase mentre in .NET si utilizza la PascalCase. Essendo xml case sensitive spesso�porta alla rinuncia della nomenclatura PascalCase. Con queste due classi in pratica si fa ignorare il casing dei nomi.

Tags: XML

Continua a leggere Libreria per XML.

Persistere automaticamenti i controlli con il ViewState (parte 1°)

Cristian "Ricciolo" Civera — Wed, 07 Sep 2005 17:49:00 GMT

Prima di buttarmi nel futuro raccontadovi ci� che seguir� a PDC voglio restare nel presente parlandovi di un problema comune.
Capita spesso di dover creare controlli a runtime in base alle informazioni date dall'utente, da una fonte db o xml e la prima volta che l'abbiamo fatto�credo che tutti (almeno io, cascato in pieno)�ci siamo trovati di fronte a seguito�di un�postback alla misteriosa scomparsa di essi.
A dir la verit� i controlli sono sempre creati a runtime, anche quelli presenti nei file aspx e ascx, solo che�il codice � persistito nei files temporanei e viene rieseguito ad ogni richiesta della pagina.
Dobbiamo infatti ricordarci che ogni richiesta � soddisfatta con una nuova istanza della nostra classe Page, di conseguenza i controlli e tutto ci� che � stato fatto viene perso.
La soluzione che di solito adotto consiste nel memorizzare nel ViewState le informazioni minime indispensabili per ricreare almeno lo stesso albero di controlli presente alla richiesta precente.
Per esempio se dal db prelevo 10 records che mi indicano di creare 10 TextBox con un certo colore e dimensione, mi limiter� a memorizzare solo il numero 10 nel ViewState. Questo perch� al postback della pagina il numero delle TextBox � sufficiente per creare la stessa lista di controlli. Per il resto ci penser� il ViewState di ogni controllo che di default memorizza tutte le sue propriet� di colore, style e dimensione.
L'ho probabilmente gi� detto, ma lo ripeto. Questo codice:

TextBox t1 = new TextBox(); t1.ForeColor = Color.Red; this.Controls.Add(t1);

� diverso da:

TextBox t1 = new TextBox(); this.Controls.Add(t1); t1.ForeColor = Color.Red;

Il primo infatti non persiste nel ViewState la propriet� ForeColor e potrebbe portare a risultati inattesi. Viceversa potrebbe essere utile, per ottimizzare il ViewState solo in certe propriet�, il primo codice.

Continua a leggere Persistere automaticamenti i controlli con il ViewState (parte 1°).

AJAX: tocca a me...

Cristian "Ricciolo" Civera — Sat, 20 Aug 2005 14:11:00 GMT

Mi ero promesso di non parlarne, ma non riesco a resistere alla tentazione ora che Boss Hogg mi ha chiamato in causa. E' buffo come dell'argomento ne parlano soprattutto chi vuole frenare la moda del momento: AJAX.

Sebbene abbia realizzato le ClientPages che appunto sfruttano XmlHttp non vuol dire che ne condivido l'uso spropositato. Mi�era�passato per la testa di realizzare controlli pi� complessi come DataGrid che si popolano o notificatori di operazioni�senza effettuare postback, ma poi ho rinunciato perch� l'ho ritenuto troppo pericoloso.
Purtroppo per� qualcosa di simile sar� implementato in Atlas. Dico purtroppo perch� gi� oggi spesso trovo utenti che fanno confunsione tra client e server, tra JavaScript e .NET e AJAX potr� aumentare tutto questo disordine.
I commenti che si leggono non sono contro l'adozione da parte�di Microsoft di questa tecnologia, ma semplicemente vogliono istruire noi tutti nell'usarli con moderazione. Semplicemente la mia idea per far si che ci� avvenga � quella di progettare i siti come si � sempre fatto e considerare DropDown che si popolano al volo, operazioni di Drag&Drop ecc solo qualcosa di optional, di pi� e solo se supportato dal browser. Cos� non mineremo l'usabilit� e l'accessibilit� del sito.
Se poi l'esigenza si fa pi� forte allora � meglio pensare a qualcosa di pi� adeguato alla situazione come gli SmartClient: applicazioni WinForms connesse ad Internet che sanno lavorare in modalit� Online/Offline.

Ritornando ad Atlas mi � venuto in mente solo ora che l'anno scorso proposi di usare Ajax sfruttando l'adaptive rendering in base alla mie esperienza con le ClientPages.
Spero comunque in una implementazione ben fatta, magari con pochi controlli e che soprattutto sincronizzino il ViewState ad ogni ClientCallback cos� da poter mixare postbacks con clientcallbacks.

Tags: AJAX

Continua a leggere AJAX: tocca a me....