LINQ to SQL: dove utilizzarlo

Ho letto ieri sera questo post di Dinesh Kulkarni, uno dei PM di LINQ to SQL. Trovo che sia molto interessante in quanto fornisce le motivazioni di alcune scelte prese nel disegno dell'architettura di LINQ to SQL e fornisce suggerimenti su quale sia il modo più corretto di utilizzarlo nelle applicazioni reali. In particolare trovo interessante il fatto che Dinesh evidenzi quelli che ad oggi sono ritenuti alcuni dei "limiti" di LINQ to SQL giustificandone il perché. 

Quello che si evince è il fatto che LINQ to SQL è principalmente pensato per implementare il data layer, come spieghiamo da ormai parecchio tempo nei corsi e negli eventi su LINQ, oltre che nel libro su LINQ che ho scritto con Marco. Nei casi in cui, secondo me ormai rarissimi per non dire inesistenti, non dovesse servire un business layer si può pensare di usare LINQ to SQL direttamente dal presentation layer, per esempio con il LinqDataSource di ASP.NET 3.5. Quest'ultimo è uno scenario adatto a soluzioni "semplici" spesso prototipali. Secondo me in tutti gli altri casi servirà un business layer che si baserà su di un data layer sottostante astratto e creato tramite un factory. Il factory, nel caso di Microsoft SQL Server, potrà essere basato su LINQ to SQL, ma il tutto dovrà risultare trasparente ai layer superiori. Può invece risultare utile sfruttare le query LINQ ai vari livelli, sapendo che nel caso di adozione di LINQ to SQL queste potranno essere convertite in statement SQL generati da LINQ to SQL o in stored procedure ad hoc, a seconda dei casi.

Come si evince dal paragrafo precedente dissento un po' dall'idea di non implementare per nulla il business layer e utilizzare al suo posto dei partial method o delle partial class sul data model ottenuto dal DBML o da SQLMetal, come ipotizzato da Dinesh. Ritengo infatti che sia meglio disaccoppiare business layer e data layer, per avere sempre e comunque idipendenza dallo storage fisico, oltre a prevedere nel business layer tutte le logiche applicative, di sicurezza e di validazione. Avere una fusione a livello di data layer di questi concetti porterebbe ad essere vincolati ad un unico motore DBMS, aspetto che di solito trovo limitante nell'architettura delle soluzioni software moderne.

Ultime note da rilevare sono la considerazione sul fatto che il DataContext e il framework di entità generate da LINQ to SQL, in una delle possibili modalità (SQLMetal o DBML da designer), sono pensati per essere leggeri. Ho notato anche io nei miei test e nelle mie prove che è sensato, in scenari distribuiti e/o fortemente disaccoppiati, come servizi SOAP o pagine ASP.NET 3.5, sfruttare DataContext dedicati ad operazioni atomiche, piuttosto che creare un unico DataContext condiviso a livello di Application Domain. D'altra parte i metodi di Attach e lo stato di detached sulle entità servono anche per questi scenari. Anche gli esempi forniti da Scott Guthrie sono molto chiari ed evidenti in questo senso.

Ormai ci siamo quasi … non vedo l'ora che sia disponibile .NET 3.5 in versione RTM così da poterlo integrare e "misurare" in alcune soluzioni.