Partiamo da un concetto: LINQ To SQL è fantastico. E' un ORM For Dummies nel senso che ha una facilità di apprendimento ed utilizzo semplicemente impressionante ed una serie di feature comunque sufficienti per poterci basare un'applicazione. Molti definiscono LINQ To SQL un ORM For Dummies perchè limitato a SQL Server, non Persistence Ignorant e con feature molto ridotte rispetto a giganti come NHibernate; tuttavia, io credo sia solo invidia per l'intellisense in Visual Studio ed il Compile Time Checking delle query :).

Eppure, nonostante tutto, ci sono quelle cose che sembrano punture di zanzare ma in realtà sono pugnalate al cuore. La principale è: le politiche di fetching si possono impostare solo sul DataContext ed una sola volta. All'inizio, LINQ To SQL permetteva di decidere a livello di query come tirare giù le associazioni dal db, se in eager o in lazy loading. Per default, le entità associate venivano caricate in lazy con la possibilità di cambiare, tramite LoadOptions, in eager. Questa possibilità, in realtà, rappresentava un problema per il team di sviluppo che doveva gestire una serie di casistiche di caricamento eccessive, quindi è stata tagliata la testa al toro e si è spostato il tutto sul DataContext invece che sulla singola query.

Qui saltano fuori i doloretti. Se io volessi tirarmi giù una fattura ed i suoi dettagli, e poi un cliente ed i suoi ordini (il tutto in eager loading), e volessi utilizzare lo stesso DataContext l'unica via è impostare a priori le politiche di fetching cioè quando si crea il DataContext. Infatti, se lo facessi nel metodo che esegue la query, mi ritroverei con una bella eccezione quando recupero i clienti perchè il fetching è stato impostato già una volta nel metodo che ritrova la fattura.

Come detto, l'unica via è impostare in fase di creazione del DataContext tutte le politiche di fetching che questo dovrà seguire. Ovviamente la cosa va fatta contesualizzata; se la si facesse generalizzata, si caricherebbero sempre gli ordini di un cliente anche se si vuole recuperare solo il suo dettaglio. Per fare questo, è la pagina stessa che deve inviare al DAL le informazioni su come caricare le cose che poi verrano cercate. Questo implica che se dobbiamo modificare una politica di fetching dobbiamo farlo in tutte le pagine coinvolte.

Alla fine, dopo averci ravanato un pò sopra, sono arrivato alla mia idea definitiva di come utilizzare LINQ To SQL in un 3 tier con tutti i compromessi che ne derivano, ma sarà argomento di un post entro le 48 ore :)


Stay Tuned...