Entity Framework e LINQ To SQL - Conflitto di interessi?

Question

Ho letto sulla blogosfera la scorsa settimana che Linq to SQL è morto [e lunga vita EF e Linq alle entità]. Ma quando ho letto la panoramica su MSDN, mi è sembrato che Linq to Entities generasse eSQL nel modo in cui Linq to SQL genera query SQL.

Ora, poiché l'implementazione sottostante (e poiché SQL Server non è ancora un ODBMS) è ancora un archivio relazionale, a un certo punto il framework Entity deve effettuare la conversione in query SQL. Perché non risolvere i problemi di Linq su SQL (m: m relazioni, solo supporto SQL server ecc.) E usare Linq in SQL come livello che genera queste query?

È a causa delle prestazioni o EF utilizza un diverso modo di trasformare l'istruzione eSQL in SQL?

Mi sembrava - almeno per la mia mente ignorante - un adattamento naturale al dogfood Linq a SQL in EF.

Commenti?

Answer 1

Vale la pena notare che Entity Framework ha (almeno) tre modi di essere consumato:

• LINQ to Entities oltre Object Services oltre Entity Cliente
• Entity SQL oltre Servizi Oggetto su Entity Cliente
• Entity SQL utilizzando Entity oggetti comando client (più simili a ADO.NET classico)

Entity client infine sputa una rappresentazione del comando ESQL (in un modulo canonico di database indipendente) che il provider ADO.NET per lo specifico RDBMS è responsabile della conversione in SQL specifico del negozio. Questo è il giusto modello di IMHO poiché nel corso degli anni è stato investito molto tempo (e continuerà ad essere investito) nella produzione di ottimi fornitori ADO.NET per ogni negozio.

Poiché Entity Framework deve funzionare con molti negozi e quindi molti provider ADO.NET, c'è meno possibilità per loro di ottimizzare facilmente ciò che il client Entity genera su base per negozio (almeno - questo è dove siamo con v1) . Il team LINQ to SQL ha avuto un problema molto più piccolo da risolvere: "funziona solo con SQL Server" e quindi potrebbe rendere più facilmente le informazioni specifiche. So che il team EF è consapevole del fatto che ci sono casi in cui EF a SQL Server sta producendo TSQL in modo meno efficiente rispetto a L2S e stanno lavorando per migliorare questo per V2.

È interessante notare che questo modello consente di aggiungere nuove funzionalità tra Entity Client e ADO.NET Provider per un negozio. Questi "wrapping provider" possono aggiungere servizi come la registrazione, il controllo, la sicurezza, la memorizzazione nella cache. Questo è discusso come caratteristica V2 sopra a http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

Se si guarda Perciò il quadro più ampio si può vedere che sarebbe stato terribilmente difficile e in effetti restrittivi di provare e in qualche modo retrofit L2S generazione TSQL nella archiecture di Entity Framework.

Answer 2

Una grande differenza tra Linq a SQL e Entity Framework è che EF implementa la specifica del modello di dati di entità (EDM) e ci sono altri prodotti che sono costruiti attorno all'EDM, come ADO.NET Data Services (aka Astoria).

L'EDM viene ora utilizzato per estendere l'AtomPub in una nuova specifica denominata Open Data Protocol (OData http://odata.org/), che viene utilizzata per allineare CRUD sopra REST.

Answer 3

In realtà, l'EF non genera EntitySQL durante la traduzione di query LINQ.Nell'EF abbiamo una rappresentazione basata sulla struttura dei dati per tutte le query denominate CQT o alberi di query canonici. Sia il traduttore LINQ che il parser EntitySQL producono CQT e il resto della pipeline di traduzione query utilizza CQT (e altre forme intermedie interne), che dopo varie trasformazioni lo rendono al provider ADO.NET (come CQT a livello di negozio), che è quindi responsabile della traduzione nel dialetto SQL del backend. Quindi i percorsi sono LINQ -> CQT -> SQL o EntitySQL -> CQT -> SQL.