Utilizzeresti LINQ to SQL per nuovi progetti?

StackOverflow https://stackoverflow.com/questions/391486

Domanda

Ho studiato quale livello dati utilizzare per un nuovo progetto basato sul Web che sto progettando e sono molto ansioso di incorporare LINQ to SQL.La sua apparente semplicità, flessibilità e supporto del designer sono davvero attraenti e il collegamento implicito a SQL Server va bene.

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

Tenendo presente questo, mi consiglieresti di utilizzare questa tecnologia per il mio progetto o vale la pena selezionare un ORM alternativo (nHibernate?) 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 verrà utilizzato principalmente come prototipo per osservare la tecnologia futura di .NET.Tuttavia, baserò i progetti futuri su ciò che imparerò da questo, quindi le scelte che farò influenzeranno le soluzioni più ampie a venire.

E sì, mi rendo conto che Microsoft probabilmente lancerà comunque domani una tecnologia di accesso ai dati completamente nuova!;)

È stato utile?

Soluzione

Bene, è già ampiamente trattato nelle risposte qui (anche alcuni punti di vista interessanti), ma lo dirò comunque di nuovo..

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

Prendiamo ad esempio l'Auto Paging con LinqDataSource.Se non specifichi Ordina per/Raggruppa per, è abbastanza economico.Inserisci l'ordine o il raggruppamento nel mix e inizi a ottenere un picco nelle prestazioni (diventa molto loquace).Quindi devi praticamente scrivere la tua implementazione di paginazione (il 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, poiché L2S è specificamente creato per interrogare SQL Server) e concettualmente e simanticamente, gran parte di LINQ a SQL è simile a EF, ma il punto in cui si incontra il muro è l'espansione delle esigenze e la considerazione di requisiti di implementazione più complicati.

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

COSÌ..in breve..Lo affronterei così:

a) imparare LINQ to SQL come introduzione (ai pattern e alla tecnologia ORM di Microsoft).ti consente di familiarizzare con la maggior parte dei fondamenti condivisi con Entity Framework e un assaggio delle query in stile LINQ (un gusto acquisito se hai un background in T-SQL)

b) una volta che hai acquisito familiarità con LINQ to SQL, ti consiglio di passare a Entity Framework per apprendere i vantaggi aggiuntivi (eSQL ecc.)

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

Altri suggerimenti

Pick NHibernate. Rimarrà in giro per qualche tempo come un concetto o l'ORM vero e proprio. Così sarà utile per imparare sia.

IMO, tutta questa cosa è stata davvero gonfiato a dismisura.

Microsoft non ha detto che LINQ to SQL sarebbe morto. Hanno più indicato che si sarebbe fusa per incorporazione in Entity Framework.

Vorrei concentrarsi sull'uso di Entity Framework come una soluzione, sapendo che gran parte del LINQ to SQL uscirà in esso.

Non c'è davvero molta differenza in questo momento comunque. Il problema maggiore è che Entity Framework non è leggero. Ritiene che importa fino a quando si dispone di una buona separazione tra i tuoi livelli?

L2S è, secondo me, perfettamente bene così com'è e come hai detto, non sta andando da nessuna parte. La società per cui lavoro ha reso il nostro standard per l'accesso ai dati e stiamo usando per tutto, dalle piccole 5 applicazioni utente di nicchia a 1000 applicazioni aziendali di utenti con ottimi risultati.

Credo che gli obiettivi del EDM la nostra molto più grandi di quelli di LINQ to SQL. Se siete alla ricerca di un semplice ORM poi penso LINQ to SQL è la strada da percorrere. Se hai intenzione di costruire in classi che hanno una struttura di ereditarietà in relazione alle tabelle di database che hanno una struttura relazionale e fare altre mappature avanzate, quindi EDM potrebbe essere una buona scelta.

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

L2S è una tecnologia impressionante, e non avrei mai tornare al vecchio ADO.

Ma come lei ha ricordato, si sta prendendo un sedile posteriore a L2E. L2S è più che capace e ho hanno fatto numerose applicazioni con esso e sono stati estremamente soddisfatti. Ma sentendo che non sarà più avanzato messo un coltello nel fianco. Così sono andato a controllare L2E ed è quasi la stessa cosa quando si tratta di SQL interazione, e per molti versi mi è più facile, per non parlare più efficiente, con la sua gestione relazione. 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'errore evitamento è seconda a nessuno. Io personalmente magra per L2E in quanto sarà sviluppato in modo più aggressivo thatn L2S.

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

In primo luogo ciò che è necessario rendersi conto in anticipo è, oggetti DataContext sono destinati a durare solo finché unità di lavoro , punto. Inoltre, DataContext di sono apolidi. Una volta che si arriva alle prese con questi due principi, utilizzando LINQ in un ambiente a più livelli inizia a lavorare bene.

D'altra parte, si vedrà un certo numero di persone raccomandare alcuni modi molto molto molto male a utilizzare LINQ. Non bisogna mai fare le vostre DataContext statico, questo è un errore che ho fatto nella fase iniziale e ha funzionato meraviglie fino a quando non ha funzionato, allora era assolutamente orribile con attraversamento dati non corretti attraverso diverse sessioni, ecc In poche parole, questo è forse il più grande più gigantesco no-no di utilizzare Linq e dovrebbe essere scritto in lettere grandi in grassetto in ogni documento. Inoltre, persistendo una DataContext in una variabile di sessione è un altrettanto cattiva idea.

L'unico altro grande brutto mi sono imbattuto in con LINQ è quando si fa un aggiornamento disconnesso, è necessario utilizzare lo stesso DataContext tutta la chiamata. Ad 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 della stessa DataContext si dovrebbe recuperare l'oggetto esistente, aggiornare i suoi valori, quindi sostengono che i cambiamenti. Tenere tutti i compiti come all'interno dello stesso DataContext.

Vorrei raccomandare L2S però, una volta a superare alcuni problemi fastidiosi (come sopra), si tratta di una grande tecnologia e sicuramente un risparmio di tempo. Vorrei tuttavia consigliamo di fare un sottile involucro intorno al vostro DAL, in modo da poter cambiare facilmente. Sto considerando (per motivi economici) porting una parte del mio codice per utilizzare OpenAccess ORM -> MySql per una parte del mio accesso ai dati, e con uno strato correttamente definito, questo compito deve solo ancora un paio d'ore.

Sono d'accordo con Echostorm. L2S è un bene per le vostre esigenze. Ed è abbastanza facile da lavorare ...

Se si progetta la vostra applicazione correttamente e isolare l'accesso dei dati strato bene, si dovrebbe andare con L2S. Da quello che deduco dal tuo post, non è un grande progetto, in modo da L2S dovrebbero soddisfare le vostre esigenze più che bene, mentre pianura vecchio ADO.NET è solo un-no no, e Entity Framework, è ... basta non usarlo , ok? In ogni caso, se si isolare bene il vostro DAL, è possibile scambiare L2S a qualcos'altro in futuro, se il progetto cresce. e anche se L2S non sta andando da nessuna parte, non va da nessuna parte. MS smesso di investire in essa, ma non sta per diventare deprecato o qualcosa, quindi è ancora un investimento sicuro. In alternativa, si dovrebbe valutare NHibernate, che è semplice e maturo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top