Cosa dicono di LINQ
La settimana scorsa ho avuto l'opportunità di presentare alla European PASS Conference 2008 il mio lavoro sulle relazioni molti-a-molti tra dimensioni in Analysis Services e la possibilità di usarle per scopi "non convenzionali" nella modellazione multidimensionale. Chiaramente, in una conferenza su SQL Server, questo non era l'argomento più "caldo" e ciò di cui mi sono trovato a parlare spesso con partecipanti e speaker riguardava direttamente o indirettamente LINQ.
Purtroppo, alcune delle preoccupazioni che io e Paolo condividevamo prima di scrivere due libri sull'argomento si stanno rivelando reali. Due "problemi" vengono percepiti da chi vede LINQ per la prima volta (relativamente a persone che hanno a fare con i database, questo va chiarito). Primo, LINQ viene associato a LINQ to SQL. Secondo, "se il codice SQL non lo posso controllare, che fine fanno le prestazioni"?
Devo dirlo, comincio a preoccuparmi per il fatto che, se questa sarà la percezione di LINQ, essa creerà problemi nella diffusione e soprattutto nel corretto uso di LINQ. Per cominciare, non credo che LINQ to SQL sia l'implementazione più importante di LINQ. Ciò che ritengo importante è l'approccio a un modello di programmazione più dichiarativa che contestualmente semplifica il modo con cui i dati vengono trattati all'interno di un programma. Se ci si concentra su una singola implementazione significa che si trascura l'aspetto pervasivo di LINQ rispetto alle diverse fonti dati che si possono gestire. Dal mio punto di vista, LINQ to Objects è l'implementazione più importante di LINQ - il rischio è che la si consideri invece un accessorio privo di reale importanza, mentre è da lì che si dovrebbe partire.
Per quanto riguarda l'aspetto prestazionale, è evidente che ciò dipende da molteplici fattori ma ancora una volta c'è un errore di percezione. Il fatto che esista uno strumento non significa che lo si debba usare. Se ho un'automobile in garage, posso anche prenderla per andare a comprare il giornale all'edicola distante 300 metri, ma ci sono altri mezzi di trasporto più efficienti (anche in termini di tempo, oltre che di costi e consumi). Assumere che a priori si debba sempre usare lo stesso strumento indipendentemente dal lavoro che va effettuato è un errore. Molte applicazioni possono trarre vantaggio da LINQ to SQL. In molte altre, non avrebbe senso utilizzarlo. E' più ragionevole parlare di confronto tra LINQ to SQL e prodotti di ORM come NHibernate, perché pur essendo implementazioni molto diverse tra loro, per lo meno il terreno di confronto è simile.
Ragionerò ancora molto su queste cose preparando le sessioni per DevCon 2008. Se qualcuno vuole contribuire alla discussione, i commenti sono aperti.