Non è morto, ma Microsoft è ora focalizzato su Entity Framework.
Ho usato LINQ to SQL su piccoli progetti, ed è piuttosto bello come un livello di dati leggero e vorrei prendere in considerazione l'utilizzo di nuovo su progetti di dimensioni simili. La stessa implementazione LINQ è veramente buona e fino a poco tempo fa molto migliore del progetto LINQ di NHibernate. Nel progetto più ampio in cui ho usato L2S, ho trovato difficile trovare un modello di unità di lavoro di cui ero soddisfatto, a causa delle limitazioni con la classe DataContext di L2S. Cercare di implementare qualcosa come "Sessione per richiesta" con L2S sembra molto difficile o impossibile.
Inoltre, non considererei L2S un vero ORM, in quanto non offre molte opzioni di mappatura. Il tuo design di classe deve davvero seguire lo schema del tuo database (tabella per classe) altrimenti combatterà con te in ogni fase del percorso. Un'altra cosa che non mi piace di L2S è la necessità di utilizzare tipi specifici ( EntitySet e EntityRef ) per gestire collezioni, riferimenti e caricamento lento. Ciò significa che non è possibile mantenere agnostico il tuo modello di dominio ORM senza aggiungere un altro livello di astrazione.
Il mio altro problema con L2S è l'unico affidamento a LINQ per generare query. Il provider LINQ è scritto molto bene e in genere crea un SQL decente per la maggior parte delle query, ma ho il mio timore che ci siano domande più complesse che non possono essere espresse bene con LINQ. In L2S, in pratica, devi tornare a chiamare le stored procedure in questi casi, mentre (ad esempio) NHibernate ha diverse API (provider LINQ, QueryOver, HQL ecc.) Che possono essere utilizzate quando vuoi un maggiore controllo sullo SQL generato.
Nella difesa di L2S su NHibernate, ci sono un sacco meno spese generali per farlo funzionare su un progetto.