Da diversi mesi ormai mi sono avvicinato (di soppiatto 
) a LINQ ed alle due diverse declinazioni che esitono per il mondo dei database.
Di LINQ To SQL ormai esistono diversi esempi e persino un piccolo "corso" tenuto da Scott Guthrie in persona:
http://weblogs.asp.net/scottgu/archive/2007/09/07/linq-to-sql-part-9-using-a-custom-linq-expression-with-the-lt-asp-linqdatasource-gt-control.aspx
Linq To Entities è ancora un pò un oggetto misterioso ed essendo ancora in CTP in pochi hanno deciso di metterci su le mani.
A chi approcia per la prima volta al mondo LINQ, la differenza tra le due versioni in questione potrebbe non essere immediata.
Dato che è inutile - in epoca di web 2.0 - riscrivere cose già dette da altre persone autorevoli, per una spiegazione ad alto livello della della cosa vi lascio alla lettura di questo post di riferimento:
http://blogs.msdn.com/pietrobr/archive/2007/11/06/linq-to-sql-e-linq-to-entities.aspx
Per quanto concerne invece la pratica - che è sempre tipicamente la parte divertente del discorso - per aiutare tutti coloro che si accingono ad usare LINQ ho preparato un esempio che mostra come, utilizzando uno stesso database di prova, ci siano delle grosse differenze in termini archietturali tra le due versioni di LINQ.
http://community.ugiss.org/files/folders/files/entry3031.aspx
Differenze che si vedono macroscopicamente, ad esempio, quando si tratta di dover gestire delle relazioni molti-a-molti tra due entità.
In LINQ to SQL, dato c'è che un mapping 1:1 (o al massimo 1:n se per un tabella definiamo una gerarchia di classi) con le tabelle del database ci dobbiamo portare dietro anche la tabella di associazione, dovendo quindi gestire un'entità che in un Domain Model disegnato nativamente, e non ricavato dal modello relazionale del database, non ci sarebbe mai stata.
Con LINQ to SQL, inoltre, le nostre classi saranno fortemente legate alle tabelle, tanto che gli oggetti di supporto di LINQ to SQL si chiamo essi stessi "table" (System.Data.Linq.Table).
Questo ovviamente non è bello, il modello ad oggetti non è libero di essere quello che dovrebbe, ma di bello c'è che in questo modo lo sviluppo di applicazioni richiede molto meno tempo, e per applicazioni la cui vita è breve e quindi il ciclo dello sviluppo deve essere anch'esso breve, la soluzione è sicuramente molto interessante.
Per applicazioni in cui non è pensabile avere il Domain Model derivato dal Modello Relazionale del database (nè viceversa!!!!) c'è LINQ to Entities ed in generare l'Entity Framework.
Con questo approccio abbiamo molta più libertà nel disegnare database e Domain Model. Ognuno può essere modellato secondo i proprio canoni: ci penserà poi l'Entity Framework a gestire il mapping in modo automatico (dopo averlo adeguatamente istruito definendo un file XML che descrive come deve avvenire il mapping)
Per approfondire la conoscenza dell'Entity Framework è caldamente consigliata questa lettura:
The ADO.NET Entity Framework Overview
La cosa bella due due approcci è che in entrabi è possibile specificare di utilizzare di usare le proprie stored procedure per accedere ai dati presente nelle tabella. E questo è sicuramente fondamentale per garantirci manutenibilità e flessibilità del database. Le prossime prove che voglio fare sono proprio legate a questa feature.