Innanzitutto, doveroso fare una distinzione: ciò di cui stai parlando è Linq to SQL, l'estensione di Linq orientata all'interrogazione di database MS SQL Server. Linq è molto di più e serve a molto altro.

Detto questo, se le performance sono un requisito cruciale del tuo programma, allora forse Linq2SQL non è la scelta perfetta. Però c'è da valutare attentamente cosa intendi per performance. Ho utilizzato stored procedures per più o meno tutto ciò che interessa il dialogo programma-db fino a un'annetto fa. Ho accolto con entusiasmo Linq2SQL e con il tempo credo di essere giunto ad una via di mezzo. Linq2SQL è semplicemente imbattibile per le operazioni CRUD: non c'è a mio modo di vedere un altro modo per selezionare, inserire, modificare e aggiornare un singolo dato efficace quanto Linq2SQL. Questa sorta di OR/M però perde parecchio quando si tratta di operazioni massive di insert, update o delete. Ma quante volte all'interno di una classica applicazione di gestione sono coinvolte queste operazioni? Poche, in percentuale: in questi casi Linq2SQL mappa tranquillamente delle stored come metodi. Può essere una via.

Chiudo il post (ma sarei felice di sentire anche il parere di altri e approfondire) dicendo che (secondo me, purtroppo) Microsoft ha già da tempo detto che non approfondirà lo sviluppo di Linq2SQL: tutto è spostato su Entity Framework e pare che la fine del predecessore sia già segnata dalla partenza. I motivi sono tanti, anche se non mi sento di condividerli tutti..

tk