Marco Russo

.NET, Business Intelligence e dintorni

Corsi

Miei blog in inglese

Quando usare LINQ to SQL?

Un commento al mio post precedente su ADO.NET Entity Framework contiene la domanda fatidica:  che fine farà LINQ to SQL? E implicitamente ne contiene un'altra altrettanto importante: quando usare LINQ to SQL?

Andiamo con ordine: LINQ to SQL sarà supportato per almeno 10 anni. Fa parte di .NET Framework 3.5, la sua interfaccia pubblica sarà mantenuta anche nelle prossime versioni di .NET Framework. Difficile che facciano marcia indietro su questo, almeno nel breve. Ma sicuramente potrebbero cambiarne l'implementazione. Questo è un argomento molto più complesso che però non siamo in grado di analizzare almeno fino a che non vedremo (a PDC 2008?) quali sono i piani per .NET 4.0. Nella peggiore delle ipotesi, non evolverà dallo stato attuale.

Ciò detto, veniamo alla seconda domanda, che non può non tenere conto delle considerazioni precedenti. Premetto che quello che segue è una mia personale opinione e non rappresenta una posizione espressa da Microsoft in alcuna sede, ufficiale e non.

LINQ to SQL va bene in molti scenari che mi trovo ad affrontare con una certa frequenza. Raggruppati per categorie:

  • Procedure batch di trasformazione/elaborazione di dati.
    • Tipicamente sono fatte apposta per un database (SQL Server nel nostro caso) e sono scritte in C# perché con T-SQL o SSIS non si avrebbe a disposizione uno strumento adeguato
    • Esempi: algoritmi di valorizzazione del magazzino; procedura di import formati custom (binari o ascii con strutture variabili); ...
  • Semplici interfacce di manutenzione di un database (es. a scopo amministrativo, edit tabelle di configurazione et simili)
  • Accesso a database locali (es. per contenere dati di configurazione)

Probabilmente ve ne sono altre, ma è importante sottolineare quello che manca e che oggi non scrivere usando LINQ to SQL:

  • Applicazioni enterprise e/o n-Tier (salvo usare LINQ to SQL per alcune parti del DAL, ma la cosa richiederebbe una lunga discussione)
  • Framework per sviluppo ERP
  • Implementazioni ERP - insomma il classico "gestionale"

I motivi per non usarlo in questi casi sono sia implementativi (prestazioni, architettura, ecc.) che strategici (supporto nel lungo periodo, evoluzione in versioni future, ecc.). Mentre i motivi per usarlo nei casi che ho esposto in precedenza sono riassumibili in una parola: produttività.

Ho usato LINQ to SQL in alcuni casi dove ho potuto confrontare il risultato ottenuto con la realizzazione corrispondente senza LINQ to SQL. Semplicemente, aumenta la produttività. Si scrive meno codice, quello che c'è è più leggibile e non si perde troppo in prestazioni (a meno che non dobbiate scrivere molti dati - purtroppo non c'è un supporto diretto al bulk insert e bisogna ricorrere ad ADO.NET). Qualche preoccupazione in più per la gestione degli errori, problematica che però negli scenari che ho descritto è di solito meno critica.

Un aspetto determinante nell'usare LINQ to SQL negli scenari che ho descritto è la facilità di deployment. Se c'è .NET 3.5, c'è tutto quello che serve. Non ci sono altre DLL o altri componenti da installare. Sarà banale, ma su applicazioni con poche centinaia di righe di codice il fatto di dover installare delle librerie aggiuntive su dei server (penso ai batch notturni) può diventare un problema peggiore dei vantaggi dati dall'uso di LINQ to SQL.

Sarei felice di avere dei feedback a queste considerazioni, soprattutto se avete già iniziato a usare LINQ to SQL.

Posted: lug 03 2008, 02.00 by marco | with 5 comment(s) |

Comments

StefanoPaparesta said:

Io scrivo software per gestire la tracciabilità e la gestione di impianti di macellazione e sezionamento. Diciamo che sono software che vengono utilizzati contemporaneamente da decine di persone, per cui credo che tranquillamente li mossiamo definire "NON ENTERPRISE". L'unica cosa che volevo aggiungere è la divisione in tier diversi utilizzando WCF. Alla luce di ciò credo che se usassi LinqToSql non avrei grossi problemi a livello di prestazioni e come dici tu la produttività avrebbe un'impennata notevole. E' vero che magari sul lungo periodo dovrei tenere conto di una sostituzione del DAL, ma voglio dire non sarebbe la prima nè l'ultima volta. Oggi sto usando Nhibernate, che devo dire funziona benissimo, ma su alcune cose non lo trovo semplice da usare, io non mi trovo bene con HQL e criteria, forse anche perchè non sempre è facile trovare documentazione adatta. Ultimamente ho visto che anche dal punto di vista doc il mondo Nhibernate sta migliorando, niente a che vedere però con ciò che si è già scritto di LinqTO*. Inoltre trovo che poter usare le interrogazioni linq sia, oggi, indispensabile. Su NHibernate esiste un progetto di Ayende per il provider Linq per Nh, però anche lì segue la logica dell'open source, prima o poi sarà completo. Con ciò non mi permetterai mai di dire che NHibernate non è un buon prodotto, solo che oggi a distanza di un anno e mezzo sto cercando di trovare un'architettura che sia non troppo complessa e avanzata, ma che permetta di avere buone prestazioni, integrazione con l'ambiente di sviluppo e documentazione. E in tutto questo e alla luce di quanto si dice oggi (sopratutto di ciò che ci sarà nella v2) che mi dici di ADO.Net Entity Framework ???

# luglio 3, 2008 10.05

marco said:

ADO.NET Entity Framework: io lo proverei, ma è una versione 1. Però mi chiedo: se hai un'architettura n-tier, come usi LINQ to SQL (o LINQ to Entities) nel DAL? Le entità di business quali sono? Quelle di LINQ to SQL o delle entità tue?

La cosa migliore probabilmente è un disaccoppiamento completo, con delle tue entità sul biz, ma questo significa che sul DAL il tipo di lavoro che fai sul database sfrutta veramente poco le potenzialità di LINQ to *.

Che poi nel tuo specifico caso possa andare bene LINQ to SQL o LINQ to Entities... benissimo. Se usi già NHibernate vuol dire che stai già usando un ORM e quindi è più semplice adottare una di queste tecnologie. Comunque sono entrambe a una versione 1 - sono certo che rispetto a un prodotto già sul mercato da tempo come NHibernate, dopo un po' sentirai la mancanza di qualcosa che lì avevi.

# luglio 4, 2008 2.41

StefanoPaparesta said:

Pensavo di usare delle mie entità nel BIZ e di trasferirle\inviarle verso i client con WCF. Comunque da cosa ho trovato in rete alcuni consigliano anche per NHibernate di utilizzare dei DTO per trasferire le entità per cui questo genere di lavoro lo dovrei comunque affrontare. Non ho ben capito cosa intendi quando dici che sfrutterei poco LinqTo* nel DAL, seguendo il vostro esempio che accompagna il libro se uso IQeryable (ove possibile) tra Biz e Dal mi sembra che si possa utilizzare abbastanza bene LinqTo*.

# luglio 7, 2008 10.33

marco said:

Quello che voglio dire è che se usi IQueryable su LINQ to SQL nel Biz, significa che hai usato le entità del DAL (di LINQ to SQL) nel Biz e questo, benché possa funzionare, ti vincola ad avere un legame molto forte e a "spostare" sul BIZ una logica che sarebbe più vicina al DAL. Voglio dire, se usi LINQ to SQL come DAL la cosa ha un senso, ma di fatto "appiattisci" il DAL sul BIZ. E' una scelta, ad alcuni può andare bene, in altri casi è troppo vincolante.

Se tieni i layer veramente separati, invece... non usi le entità di LINQ to SQL fino al BIZ (altrimenti non puoi sostituire agevolmente il DAL), usi delle tue entità su cui non puoi sfruttare IQueryable a meno che non scrivi un tuo provider (nel libro c'è scritto come fare, ma effettivamente non è una passeggiata).

Insomma - non c'è una risposta che va bene per tutti...

# luglio 8, 2008 9.21

StefanoPaparesta said:

Ok, adesso mi è chiaro. Boh, ci rifletto e vedo cosa fare. Sicuramente non mi creerò un mio provider, almeno per adesso. Però in effetti i layer li voglio separare. Grazie per le indicazioni, sono veramente molto utili.

# luglio 8, 2008 9.35