LINQ to SQL Dead or Alive?

Proprio quando faccio amicizia con LINQ su SQL, sembra che MS stia tirando fuori il tappeto da sotto di esso.

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

Dalla mia piccola ricerca, EF è un modo eccessivo per un lavoro semplice. Ma dopo questo annuncio c’è un punto nel continuare a usare LINQ to SQL?

Oltre il futuro per LINQ to SQL, questo non invia generalmente un segnale negativo? Data la velocità con la quale MS sta lanciando bit contro il muro, è razionale utilizzare presto uno qualsiasi dei nuovi bit? (e questo è gentile, non è ancora presto per LINQ to SQL!).

Per il mio LINQ su SQL, penso di essere diretto a SubSonic!

Aggiornamento: un paio di nuove opinioni:

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1) Non possono “uccidere” Linq-to-SQL poiché è già parte del framework .net. Quello che possono fare è smettere di aggiungere funzionalità ad esso. Ciò non impedisce alle migliaia di sviluppatori che utilizzano già L2S di estenderlo e migliorarlo. Alcune aree principali sono difficili da toccare ma sono già solide e le funzionalità di progettazione mancanti possono essere facilmente applicate .

2) Una delle sessioni EF di PDC mostra che hanno imparato un paio di lezioni dal fiasco EFv1 e ora stanno copiando e incollando molte delle chicche di L2S in EF e facendo finta che si tratti di nuove cose di EF. In altre parole, la versione 2 di L2S è stata appena etichettata come EF.

3) LINQ come tale (Language Integrated Query) è la cosa migliore dopo il gelato a fette e può essere utilizzato con molte altre cose rispetto a L2S (da Linq a oggetti, da Linq a quadro, da Linq a XML, da Linq a nulla ). Quindi il tentativo del gruppo DP di costringere [le vaste masse di] L2S ad adottare l’Entity Framework meno popolare e attualmente imperfetto non è un motivo per non apprendere Linq.

Vedi anche questo thread (che è quello in cui credo abbia triggersto parzialmente il post sul blog di Tim): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

Aggiornamento 1: Il numero di dicembre 2008 della cover story di Visual Studio Magazine di Roger Jennings è una buona lettura sull’argomento, con alcuni confronti tra L2S e EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Aggiornamento 2: Anders Hejlsberg è stato citato da Redmond Developer News dicendo che ” LINQ to SQL non è morto, posso assicurarti che non è morto, non se ne va mai niente, non l’abbiamo mai fatto e non lo faremo mai.

http://reddevnews.com/blogs/weblog.aspx?blog=3016

C’è un’ambiguità alla tua domanda che deve essere risolta.

LINQ! = LINQ a SQL

Ci sono un sacco di tecnologie e fornitori LINQ:

  • Linq to SQL;
  • Linq alle Entità;
  • Linq to Objects;
  • Da Linq a XML;

… e quelli sono solo quelli di Microsoft. Ci sono anche fornitori non MS, incluso NHibernate.

Il post sul blog che hai collegato parla solo di Linq a SQL.

Il vantaggio chiave di LINQ è che puoi imparare e utilizzare una syntax di query e riutilizzarla su più tecnologie.

Detto questo, suggerirei che qualsiasi mancanza percepita di un futuro per “Linq To SQL” è irrilevante, in quanto le abilità acquisite nello scrivere LINQ Query saranno trasferibili ad altri strumenti in futuro.

Non stiamo uccidendo LINQ to SQL. Stiamo ottimizzando per EF, ma LINQ to SQL non viene sicuramente eliminato 🙂

– Scott / Microsoft.

Non solo dovresti imparare Linq (System.Linq.Enumerable e System.Linq.Queryable), dovrai imparare i miglioramenti del linguaggio di programmazione per il tuo linguaggio .net.

In C # 3.0 questi includono:

  • Metodi di estensione (metodi statici con questa parola chiave sul primo parametro)
  • Tipi derivati ​​dal compilatore (var)
  • Sintassi Lambda (che genera un metodo anonimo o un’espressione a seconda del contesto)
  • inizializzatori
  • Implementazione predefinita della proprietà (una scorciatoia)

Leggi di più qui .


In VB 9.0 ci sono alcune magie XML inline e molte altre cose (molte sono simili all’elenco sopra per C #).

Leggi di più qui .

Onestamente non capisco dove in quell’articolo leggi che link2sql è morto.

Nel post del blog che hai collegato ad esso dice:

Stiamo ascoltando i clienti per quanto riguarda LINQ to SQL e continueremo ad evolvere il prodotto sulla base del feedback che riceviamo anche dalla comunità.

Per me questo legge come LINQ to SQL sarà sviluppato e supportato in futuro. Mi chiedo perché pensi che sia morto?

Certo, penso che la scelta tra LINQ to SQL, LINQ to Entities e LINQ to [insert 3rd Party ORM] qui fornisce un ecosistema perfettamente sano di metodologie di livello di accesso ai dati che uno sviluppatore di software può scegliere. I fornitori di terze parti come NHibernate, LLBLGen e persino Subsonic (non sono sicuro se offriranno provider LINQ) renderanno sicuramente la competizione migliore e più interessante.

Detto questo, sarà assolutamente triste per Microsoft abbandonare LINQ to SQL, soprattutto perché ha un buon seguito – anche StackOverflow è stato creato su di esso.

Post interessante su questo blog. E alcune informazioni correlate sui post Stackoverflow .

L’essenza di base sembra essere i commenti fatti sul blog di ado.net che affermano che Entity Framework è l’unica cosa che ottiene il maggiore tempo di sviluppo per Visual Studio 2010 e Dot Net 4.

La mia risposta è – DUH. Lo sappiamo tutti. Microsoft ha dichiarato pubblicamente al PDC 2007 che LINQ to SQL era una versione a breve termine per SQL Server perché non c’era altra storia LINQ su SQL Server. Funziona solo con SQL Server. Non è ansible scrivere un LINQ al provider SQL: non esiste un modello per questo. Era una tecnologia unica, non estensibile.

Entity Framework è l’UNICO metodo di Microsoft per creare un provider LINQ. L’Entity Framework si è rivelato abbastanza contraddiale, ma penso che sia in parte dovuto al fatto che LINQ to SQL ha una migliore esperienza di programmazione oggi. Entity Framework prenderà e supererà LINQ to SQL perché è lo strumento ORM / Mapping del futuro di Microsoft.

EDIT – Ho appena fatto un po ‘più dettagliato su questo sul mio blog

EDIT2 – Provider IQueryable – NON è la stessa cosa di un provider LINQ to SQL. Puoi scrivere il tuo provider IQueryable per qualsiasi cosa desideri. Non ottieni supporto per il designer o generazione di modelli. Non esiste un modello di progettazione Gui che conosca per bind la generazione del modello LINQ a SQL.

Credo di non vedere il problema qui. Dall’articolo che hai collegato:

Stiamo ascoltando i clienti per quanto riguarda LINQ to SQL e continueremo ad evolvere il prodotto sulla base del feedback che riceviamo anche dalla comunità.

Mi sto perdendo qualcosa? Cosa dà l’impressione che LINQ to SQL sia morto all’arrivo?

Scott Guthrie mi ha detto che non avrebbero ucciso LINQ to SQL:

Pubblica su LINQDev.com

Qualcuno ricorda VB6? Che lo detesti o lo ami personalmente, Microsoft ha venduto milioni di copie e le aziende spendono milioni di dollari scrivendo milioni di righe di VB6. Quello che è successo dopo?

  • Bene, Microsoft supporta ancora VB6 (tipo di – non l’IDE).
  • E Microsoft continua a dire che stanno ascoltando i clienti VB6 anche adesso ( in settembre 09 ).
  • Ma i clienti VB6 sono felici? Non dal 2002 , 4 anni dopo l’avvio di VB6.
  • Perchè no? I percorsi di aggiornamento per l’investimento del codice per la tecnologia sostitutiva, VB.Net, sono costosi .

Quindi considera quella lezione. Per me, sembra che il supporto di LinqToSQL sarà piuttosto riluttante. Sono obbligati a supportarlo perché è nell’attuale framework .NET. Ma sarà in .NET 5, 6, 7 …? Pensa solo a quanto ti importa (per quanto ne so, non ha importanza per te).

Forse non dovresti preoccuparti di imparare Linq per SQL, ma ci sono ancora le Entities Linq che manterranno.

È ovvio che 2 ORM siano uno a molti nella casella degli strumenti di Microsoft, ma a me sembra che sia stata scelta la struttura sbagliata per tutte le ragioni sbagliate. Il fatto che il team di C # ha svolto il lavoro che il team di ADO.NET doveva svolgere in tempi molto più brevi e ha svolto il lavoro in modo migliore è difficile da inghiottire per il team di ado.net. Non che conosca il funzionamento interno dei 2 framework, ma penso che sarebbe molto più rapido aggiornare le carenze di linq2sql al framework di quadro.

Sembra che ci sia troppa politica e penso che questo danneggerà davvero la reputazione di asp.net, dal momento che non ho fiducia in quel framework Entity che ci fornirà un’esperienza altrettanto user friendly come Linq2sql. Il team di ado.net potrebbe anche apprendere alcune capacità comunicative dal team di asp.net mvc poiché i chiarimenti sul problema sono nel migliore dei casi vaghi.

Sarebbe divertente imparare ciò che Scott Gu e il suo team MVC stanno qui, poiché la maggior parte dei loro esempi utilizza Linq2Sql.

Era sempre un po ‘strano che con Linq 2 Sql e Entity Framework ci fossero grandi aree di sovrapposizione. Penso che l’unica ragione per cui L2S sia mai entrato nella versione 3.5 di .NET era perché c’era un grande dubbio che EF avrebbe mai visto la luce del giorno. Ora che EF1 è fuori, tutto è un v1 molto difficile, non c’era più bisogno di L2S.

(no, StingyJack, LINQ to SQL non usa il framework quadro)

Ad ogni modo, non mi preoccuperei. Tim afferma che stanno ascoltando i clienti per quanto riguarda LINQ to SQL. A giudicare dall’entusiasmo che ho visto per L2S, i clienti (che siamo noi) parleranno le loro menti.

E, come sottolinea KristoferA, non possono realmente “uccidere” L2S, ma solo congelarlo. E L2S, una volta shiny, non richiede davvero molto ulteriore sviluppo. Con il provider L2S in atto, qualsiasi progresso in LINQ dovrebbe essere disponibile anche in L2S. Quindi la scelta sarà ancora nostra.

La prossima versione di Windows Phone 7, nome in codice Mango, include una SQL Server Compact Edition accessibile tramite Linq a SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/