Utilizzeresti LINQ to SQL per i nuovi progetti?

Question

Ho studiato il livello dati da utilizzare per un nuovo progetto web-based che sto progettando e sono molto interessato a incorporare LINQ to SQL. La sua apparente semplicità, flessibilità e supporto per i designer sono davvero interessanti e il legame implicito con SQL Server va bene.

Tuttavia, è stato recentemente annunciato che LINQ to SQL passerà in secondo piano nel Entity Framework ora che è stato passato al team di ADO.NET (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). Certo, sarà supportato in futuro, ma è improbabile che vedrà molto più lavoro di sviluppo.

Con questo in mente, mi consiglieresti di usare questa tecnologia per il mio progetto o vale la pena selezionare un ORM alternativo (nibernate?) O codificare manualmente un DAL generico?

Il progetto stesso è basato su ASP.NET e SQL Server 2005/2008 e probabilmente utilizzerà MVC, anche se è ancora in versione beta. È un progetto personale, il database non sarà eccessivamente complesso e sarà principalmente utilizzato come prototipo per guardare a .NET future tech. Baserei i progetti futuri su ciò che apprendo da questo, quindi le scelte che farò influenzeranno le soluzioni più grandi a venire.

E sì, mi rendo conto che Microsoft probabilmente introdurrà un'intera nuova tecnologia di accesso ai dati domani comunque! ;)

Answer 1

Beh, è ​​per lo più coperto di risposte qui (alcuni interessanti punti di vista così) già, ma ho intenzione di dire di nuovo comunque ..

LINQ to SQL (L2S) è molto versatile, ma sembra un po 'troppo semplice dal mio punto di vista. Nella maggior parte dei casi fa un buon lavoro nel fare cose semplici, ma non appena ne chiedi un po 'di più, diventa costoso. Questa non è affatto una brutta cosa. In realtà penso che LINQ to SQL in realtà supplenti piacevolmente il Framework Entity.

Eseguire il paging automatico con LinqDataSource ad esempio. Se non si specifica Order By/Group By, allora è abbastanza economico. Lancia ordini o raggruppamenti nel mix e inizi a ottenere un picco di prestazioni (diventa molto loquace). Devi quindi scrivere la tua implementazione di impaginazione (che non è terribilmente difficile, lo ammetto).

Sarò il primo ad ammettere che L2S ha il vantaggio rispetto a Entity Framework in termini di qualità del T-SQL generato (dovrei, dal momento che L2S è specificamente costruito per l'interrogazione di SQL Server) e concettualmente e in modo similico gran parte di LINQ to SQL è simile a EF, ma dove si colpisce il muro si stanno espandendo le esigenze e le considerazioni per requisiti di implementazione più complicati.

Se dovessi iniziare da zero e scegliere di dedicare il tempo di sviluppo personale, sceglierei Entity Framework. È interessante notare che sto lavorando a un progetto in questo momento che usa L2S e che è stato progettato per ridimensionare i carichi pesanti, ma quando raggiungiamo alcuni dei requisiti più "creativi", siamo spesso costretti ad espanderci su SQL Metal (es. relazioni molti-a-molti).

Quindi .. insomma .. mi piacerebbe avvicino così:

a) imparare LINQ to SQL come introduzione (per i modelli ORM di Microsoft e la tecnologia) ..ti dà familiarità con la maggior parte dei fondamenti condivisi con Entity Framework e un assaggio di query in stile LINQ (un gusto acquisito se hai uno sfondo in T-SQL)

b) una volta ottenuto un gestire LINQ su SQL, mi raccomando di passare a Entity Framework per apprendere i vantaggi aggiuntivi (eSQL ecc.)

c) Implementare un progetto di prova del concetto in entrambi e confrontare i risultati.

Answer 2

Selezionare NHibernate. Rimarrà in giro per qualche tempo come un concetto o l'attuale ORM. Quindi sarà utile imparare entrambi.

Answer 3

L2S è, IMHO, perfettamente a posto così com'è e, come hai detto, non sta andando da nessuna parte. La società per cui lavoro è diventata il nostro standard per l'accesso ai dati e la stiamo utilizzando per tutto, dalle 5 app di nicchia per utenti a più di 1000 applicazioni aziendali con ottimi risultati.

Answer 4

Partenza SubSonic:

http://subsonicproject.com/

Answer 5

penso che gli obiettivi del nostro EDM molto più grandi di quelli di LINQ to SQL. Se stai cercando un ORM semplice allora penso che LINQ to SQL sia la strada da percorrere. Se si pianifica di costruire in classi che hanno una struttura di ereditarietà in relazione a tabelle di database con una struttura relazionale e altre mappature avanzate, l'EDM potrebbe essere una buona scelta.

Answer 6

IMO, tutta questa faccenda è stata davvero sproporzionata.

Microsoft non ha detto che LINQ to SQL sarebbe morto. Hanno più indicato che sarebbe stato fuso in Entity Framework.

Mi concentrerei sull'utilizzo di Entity Framework come soluzione, sapendo che verrà implementato gran parte del LINQ su SQL.

In questo momento non c'è molta differenza. La più grande lamentela è che Entity Framework non è leggero. Ciò conta davvero se hai una buona separazione tra i tuoi livelli?

Answer 7

Sono d'accordo con Echostorm. L2S è adatto alle tue esigenze. Ed è abbastanza facile lavorare con ...

Answer 8

Vale la pena ricordare che questo sito è stato creato utilizzando LINQ to SQL. Jeff ha parlato di usarlo sul podcast StackOverflow.

Answer 9

L2S è una tecnologia eccezionale e non tornerò mai più al vecchio ADO.

Ma come hai detto, sta prendendo un posto indietro per L2E. L2S è più che capace e ho fatto numerose applicazioni con esso e sono stato incredibilmente soddisfatto. Ma sentendo che non sarà più avanzato metto un coltello nella mia parte. Quindi sono andato a controllare L2E ed è quasi lo la stessa cosa quando si parla di interazione SQL, e per molti versi lo trovo più facile, per non dire più efficiente con la sua gestione delle relazioni. Con tali somiglianze, sembra logico scegliere L2E.

ho scritto un post sul fare l'interruttore e confrontando i due quadri: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Posso quasi garantire che sarai felice con uno di questi quadri, che sono una manna dal cielo per lo sviluppo. La semplicità e l'evitamento degli errori non sono secondi a nessuno. Mi piacerebbe personalmente appoggiare a L2E in quanto sarà sviluppato in modo più aggressivo su L2S.

Answer 10

Se si progetta l'app correttamente e si isola bene il livello di accesso ai dati, si consiglia di utilizzare L2S. Da quello che deduco dal tuo post, non è un grande progetto, quindi L2S dovrebbe soddisfare le tue esigenze bene, mentre il vecchio vecchio ADO.NET è solo un no-no, ed Entity Framework, è ... semplicemente non usarlo , ok? Ad ogni modo, se si isola bene il DAL, è possibile scambiare L2S con qualcos'altro in futuro se il progetto cresce. e anche se L2S non sta andando da nessuna parte, non sta andando da nessuna parte. La SM ha smesso di investire in essa, ma non diventerà deprecata o qualcosa del genere, quindi è ancora un investimento sicuro. In alternativa, è necessario valutare NHibernate, che è semplice e maturo.

Answer 11

Uso L2S pesantemente sul mio progetto web corrente e credo che il più grande hangup che troverete è la documentazione in conflitto per quanto riguarda il modo migliore per lo sviluppo di database a più livelli.

Prima di tutto ciò che è necessario realizzare in anticipo, gli oggetti DataContext sono destinati a durare solo fino all'unità di lavoro, punto. Inoltre, DataContext sono senza stato. Una volta che si sono confrontati con questi due principi, l'utilizzo di LINQ in un ambiente a più livelli inizia a funzionare correttamente.

D'altra parte, vedrete un numero di persone che consiglia alcuni modi molto molto pessimi per usare Linq. Non rendere MAI il tuo DataContext statico, questo è un errore che ho fatto all'inizio e ha funzionato a meraviglia finché non ha funzionato, quindi è stato assolutamente orribile con dati errati che attraversano diverse sessioni, ecc. In poche parole, questo è forse il più grande il più grande no-no di usare Linq e dovrebbe essere scritto in grandi lettere in grassetto in ogni documento. Inoltre, la persistenza di un DataContext in una variabile Session è un'idea altrettanto negativa.

L'unico altro problema più grave che ho incontrato con LINQ è quando si esegue un aggiornamento disconesso, è necessario utilizzare lo stesso DataContext nell'intera chiamata. Per esempio:

public static void UpdateUser(UserLibrary.User user) { 
     using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr)) 
     { 
      UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault(); 
      newUser.Email = user.Email; 
      newUser.FirstName = user.FirstName; 
      newUser.LastName = user.LastName; 
      dc.SubmitChanges(); 
     }   

non si può semplicemente passare un utente creato in un DataContext diverso e si aspettano di aggiornamento al lavoro, a meno che non si imposta DataContext.ObjectTrackingEnabled = false, che io non lo consiglio. Invece, all'interno dello stesso DataContext dovresti recuperare l'oggetto esistente, aggiornarne i valori, quindi inviare le modifiche. Mantieni tutte le attività simili all'interno dello stesso DataContext.

Vorrei raccomandare L2S, tuttavia, una volta superati alcuni problemi insignificanti (come sopra), è una grande tecnologia e sicuramente un risparmio di tempo. Vorrei comunque consigliare un involucro sottile attorno al tuo DAL, in modo che tu possa cambiare facilmente. Sto considerando (per ragioni economiche) il porting di una porzione del mio codice per l'utilizzo di OpenAccess ORM -> MySql per una parte del mio accesso ai dati, e con un livello correttamente definito, questa operazione dovrebbe richiedere solo alcune ore.