Entity Framework vs LINQ to SQL

828

Ora che .NET v3.5 SP1 è stato rilasciato (insieme a VS2008 SP1), ora abbiamo accesso al framework di entità .NET.

La mia domanda è questa Quando si tenta di decidere tra l'utilizzo di Entity Framework e LINQ to SQL come ORM, qual è la differenza?

Per come lo capisco, Entity Framework (se utilizzato con LINQ to Entities) è un "fratello maggiore" di LINQ to SQL? In questo caso, quali vantaggi ha? Cosa può fare che LINQ to SQL non può fare da solo?

.net entity-framework linq-to-sql

— Chris Roberts
fonte

138

Penso che le risposte seguenti debbano essere riesaminate perché è passato molto tempo da quando EF è stato rilasciato, quindi i nuovi sviluppatori che arrivano qui possono avere l'impressione sbagliata. EF è diventato uno strumento GRANDE e FACILE sin dalla sua prima uscita. Hai appena impostato la connessione al DB ed è una specie del 90% di tutto ciò di cui hai bisogno. Sviluppo molto rapido, dal punto di vista esperto! Da lì - LINQ è il tuo migliore amico. È altamente personalizzabile, MVC lo adora e per le persone che dicono che è male - Scopri come usarlo prima (e impadronisciti anche di LINQ)!

— Graumanoz,

10

Solo così è chiaro - non è che tu abbia scelta ora - MSFT ha effettivamente ucciso LINQ2SQL a favore di EF. Tuttavia, il fatto che EF di provenienza aperta MSFT l'abbia aiutato a succhiare di meno e sta decisamente migliorando. Ma per chiunque entri in EF - assicurati di capire che ci sono ancora molte stranezze in EF. Ho postato circa un - stackoverflow.com/questions/305092/...

— nikib3ro

4

@ kape123, (a) LINQ to SQL non è "morto"; è ancora utilizzabile; (b) LINQ to SQL è il metodo di accesso ai dati standard nello sviluppo di Windows Phone 8.

— Ryan Lundy,

9

@ user3308043, [citazione necessaria].

— Ryan Lundy,

3

@Kyralessa - A partire dal 2010 (con il rilascio di .NET 4.0, la citazione più recente che ho trovato), MS ha riconosciuto che , mentre alcuni investimenti potrebbero essere fatti in LINQ2SQL, "la maggior parte del nostro investimento complessivo sarà nell'entità Struttura."

— km

483

LINQ to SQL supporta solo 1 a 1 mapping di tabelle, viste, sprocs e funzioni del database disponibili in Microsoft SQL Server. È un'API eccezionale da utilizzare per la costruzione rapida dell'accesso ai dati su database SQL Server relativamente ben progettati. LINQ2SQL è stato rilasciato per la prima volta con C # 3.0 e .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) è un'API ORM (Object Relational Mapper) che consente un'ampia definizione dei modelli di dominio degli oggetti e delle loro relazioni con molti diversi fornitori di dati ADO.Net. Pertanto, è possibile combinare diversi fornitori di database, server applicazioni o protocolli diversi per progettare un mash-up aggregato di oggetti costruiti da una varietà di tabelle, origini, servizi, ecc. ADO.Net Framework è stato rilasciato con .Net Framework 3.5 SP1.

Questo è un buon articolo introduttivo su MSDN: Presentazione di LINQ to Relational Data

— Kris
fonte

sembra che tu usi LINQ to SQL per interrogare in EF

— PositiveGuy il

11

@CoffeeAddict mentre sono molto simili nello stile usando LINQ lambdas, ogni API ha basi completamente diverse. Ad esempio, il modo in cui LINQ2SQL genera query SQL consente l'utilizzo di funzioni SQL, mentre L2E non lo fa, o almeno non lo fa dal 2008.

— Kris

2

L'approccio orientato agli oggetti EF lo rende davvero facile e comodo da usare, può essere codificato molto velocemente, gestito. Per me, solo il modo migliore per accedere ai dati.

— Antoine Pelletier,

10

Questa risposta è obsoleta. Ora Linq to SQL supporta one2many mapping

— George Lanetz,

201

Penso che la risposta rapida e sporca sia quella

LINQ to SQL è il modo semplice e veloce per farlo. Ciò significa che andrai più veloce e consegnerai più velocemente se stai lavorando su qualcosa di più piccolo.
Entity Framework è il modo completo e senza esclusione di colpi per farlo. Ciò significa che impiegherai più tempo in anticipo, svilupperai più lentamente e avrai maggiore flessibilità se lavori su qualcosa di più grande.

— Brad Tutterow
fonte

32

Inoltre, tenderai a scrivere meno righe di codice con L2S per ottenere lo stesso risultato che faresti con EF. Nessun caricamento lento in EF significa che stai sempre controllando se qualcosa è stato caricato o meno.

— Paul Mendoza,

Brad, cosa consiglieresti per un sito di e-commerce? Voglio dire, non riesco a vedere altro che semplici CRUD in corso lì ...

— PositiveGuy

2

@CoffeeAddict ovviamente, la top 3 della risposta più votata dice L2S per CRUD semplice

— IsmailS,

11

@Banford Con EF in .NET 4.0 penso che sia meglio di L2S. Le funzionalità che mancavano a EF in 3.5 che L2S erano state aggiunte a EF in .NET 4.0. Le tue dichiarazioni LINQ ora in EF in .NET 4.0 appariranno più o meno le stesse di quelle in L2S. EF ti offre alcune cose extra che puoi fare ora in aggiunta a ciò che offre L2S.

— Paul Mendoza,

40

Questa risposta ora ha 5 anni ed è abbastanza obsoleta. Entity Framework 6 è ora in versione beta ed è molto migliorato, include caricamento pigro, supporto enum, ecc.

— Tim

109

LINQ to SQL è davvero morto? di Jonathan Allen per InfoQ.com

Matt Warren descrive [LINQ to SQL] come qualcosa che "non avrebbe mai dovuto esistere". In sostanza, si supponeva che fosse solo un supporto per aiutarli a sviluppare LINQ fino a quando il vero ORM non fosse pronto.

...

La scala di Entity Framework ha causato il mancato rispetto della scadenza di .NET 3.5 / Visual Studio 2008. È stato completato in tempo per il purtroppo denominato ".NET 3.5 Service Pack 1", più simile a una versione principale che a un service pack.

...

Agli sviluppatori non piace [ADO.NET Entity Framework] a causa della complessità.

...

a partire da .NET 4.0, LINQ to Entities sarà la soluzione di accesso ai dati consigliata per LINQ per scenari relazionali.

— Zack Peterson
fonte

56

In realtà, non ci piace EF perché ha un designer così povero ed è estremamente, estremamente difettoso. Non l'ho mai trovato così complesso.

— BlueRaja - Danny Pflughoeft il

12

Molti dei principali siti di e-commerce utilizzano LINQ to SQL. Esempi: Redbox, StackOverflow, ecc.

— positivo

14

Conosco MOLTI buoni sviluppatori che usano LINQ to SQL e dicono che questi articoli sono totalmente esagerati. Sono d'accordo. LINQ to SQL è stato utilizzato in potenti .com e lo è ancora.

— Positivo

4

Sì, la chiamata a .ToString () su una proprietà intera in una query L2EF non dovrebbe causare un'eccezione.

— StingyJack,

3

@ BlueRaja-DannyPflughoeft È ancora vero dopo più di 5 anni?

— Vikas Rana,

94

Ci sono una serie di ovvie differenze delineate in quell'articolo pubblicato @lars, ma la risposta breve è:

L2S è strettamente accoppiato: proprietà dell'oggetto su un campo specifico del database o mappatura degli oggetti più corretta su uno schema di database specifico
L2S funzionerà solo con SQL Server (per quanto ne so)
EF consente di mappare una singola classe su più tabelle
EF gestirà le relazioni MM
EF avrà la possibilità di scegliere come target qualsiasi fornitore di dati ADO.NET

La premessa originale era che L2S è per lo sviluppo rapido e EF per applicazioni "di livello" più "enterprise", ma che sta vendendo L2S un po 'corto.

— JamesSugrue
fonte

13

La tua citazione "L2S funzionerà solo con SQL Server (per quanto ne so)" deve essere aggiornata: il progetto open source "dblinq" sostituisce l'assembly LINQ to SQL con uno che può parlare con MySQL, PostgreSQL, Ingres, Firebird, SQLite. .. e Microsoft SQL (ovviamente).

— Contango,

1

aspetta ... quindi EF non crea oggetti DL strettamente accoppiati?

— Positivo

7

sì, la premessa originale che L2S non è una soluzione adatta alle imprese non è più vera. Voglio dire StackOverflow funziona su L2S e un sacco di altri .com come Redbox e molti altri.

— Positivo

74

LINQ to SQL

Origine dati omogenea: SQL Server
Consigliato per piccoli progetti solo dove la struttura dei dati è ben progettata
Il mapping può essere modificato senza ricompilare con SqlMetal.exe
.dbml (Database Markup Language)
Mappatura one-to-one tra tabelle e classi
Supporta l' eredità TPH
Non supporta tipi complessi
Primo approccio allo storage
Vista incentrata sul database di un database
Creato dal team C #
Supporto ma non ulteriori miglioramenti previsti

Entity Framework

Origine dati eterogenea: supporta molti fornitori di dati
Consigliato per tutti i nuovi progetti tranne:
- piccoli (LINQ to SQL)
- quando l'origine dati è un file flat (ADO.NET)
La mappatura può essere modificata senza ricompilare quando si impostano i file modello e mappatura Metadata Artefact Process to Copy in Output Directory
.edmx (Entity Data Model) che contiene:
- SSDL (linguaggio di definizione dello schema di archiviazione)
- CSDL (linguaggio di definizione dello schema concettuale)
- MSL (Mapping Specification Language)
Mappature one-to-one, one-to-many, many-to-one tra tabelle e classi
Supporta l'ereditarietà:
- TPH (tabella per gerarchia)
- TPT (tabella per tipo)
- TPC (tabella per classe di calcestruzzo)
Supporta tipi complessi
Approcci Code-first, Model-first, Storage-first
Vista incentrata sull'applicazione di un database
Creato dal team di SQL Server
Il futuro delle API di dati Microsoft

Guarda anche:

— Ryszard Dżegan
fonte

6

Questa è la risposta più attuale e dettagliata.

— ErTR

2

Entity Framework non utilizza LINQ to SQL quando, per esempio, stai scrivendo un dbSet<Orders>.Where()...ToList()? Penso che sia fuorviante avere Entity Framework contrario a LINQ to SQL.

— Don Cheadle,

4

@mmcrae EF non utilizza L2S, entrambi sono linq-provider di database sottostanti. Se lo interpreti come Linq-to-a-database, simile a linq-to-object e linq-to-xml, sì, entrambi sono simili in linq-to-a-database. No, EF non usa L2S (o viceversa). Due strumenti completamente separati.

— Maarten,

4

"Consigliato per tutti i nuovi progetti tranne ... piccoli" Non sono d'accordo. Code First è un modo estremamente rapido per iniziare a correre con piccoli progetti. A parte questo, ottimo aggiornamento a questa domanda.

— DrewJordan,

51

La mia esperienza con Entity Framework è stata tutt'altro che stellare. Innanzitutto, devi ereditare dalle classi di base EF, quindi saluta i POCO. Il tuo progetto dovrà essere intorno all'EF. Con LinqtoSQL ho potuto utilizzare i miei oggetti business esistenti. Inoltre, non c'è caricamento lento, è necessario implementarlo da soli. Esistono alcuni modi per aggirare i POCO e il caricamento lento, ma esistono IMHO perché EF non è ancora pronto. Ho intenzione di tornarci dopo la 4.0

— Jiyosub
fonte

7

La mancanza di supporto POCO è la ragione numero uno per cui ho scelto LINQ to SQL su Entity Framework. Potrei rivisitare EF quando lo incorporeranno nella prossima versione, come promettono. Ci sono altri progetti là fuori che fanno POCO per EF, ma non abbastanza chiaramente.

— Joseph Ferris,

27

Nel caso in cui qualcuno (come me) non sappia cosa significa POCO: Plain Old CLR Object

— CBono,

4

Davvero non vedo quale sia il grande problema di non supportare i POCO ... è un altro livello di astrazione ragazzi. Crea una fabbrica, iniettando il repository di dati e costruisci lì i tuoi POCO. Probabilmente è comunque una buona idea.

— EightyOne Unite,

3

Ho sentito che POCO è possibile in EF 4

— PositiveGuy il

8

Il supporto POCO è disponibile in questi giorni e l'ereditarietà non è più un requisito per le classi di entità @CoffeeAddict POCO è solo un oggetto semplice che non fa affidamento su un framework specifico ed è una parte importante dei modelli di framework di entità moderni

— Chris McGrath

46

Ho trovato un'ottima risposta qui che spiega quando usare cosa in parole semplici:

La regola empirica di base per quale framework utilizzare è come pianificare la modifica dei dati nel livello di presentazione.

Linq-To-Sql : utilizzare questo framework se si prevede di modificare una relazione uno-a-uno dei dati nel livello di presentazione. Ciò significa che non prevedi di combinare i dati di più di una tabella in una vista o pagina.

Entity Framework : utilizzare questo framework se si prevede di combinare i dati di più di una tabella nella vista o nella pagina. Per chiarire questo aspetto, i termini sopra riportati sono specifici dei dati che verranno manipolati nella tua vista o pagina, non solo visualizzati. Questo è importante da capire.

Con Entity Framework sei in grado di "unire" insieme i dati tabulati per presentarli al livello di presentazione in un modulo modificabile, quindi quando quel modulo viene inviato, EF saprà come aggiornare TUTTI i dati delle varie tabelle.

Probabilmente ci sono ragioni più precise per scegliere EF piuttosto che L2S, ma questa sarebbe probabilmente la più semplice da capire. L2S non ha la capacità di unire i dati per la presentazione della vista.

— Nawaz
fonte

36

La mia impressione è che il tuo database sia piuttosto enorotico o mal progettato se Linq2Sql non soddisfa le tue esigenze. Ho circa 10 siti Web più o meno grandi tutti usando Linq2Sql. Ho guardato e Entity framework molte volte ma non riesco a trovare una buona ragione per usarlo su Linq2Sql. Detto questo, provo a utilizzare i miei database come modello, quindi ho già un mapping 1 a 1 tra modello e database.

Nel mio lavoro attuale abbiamo un database con oltre 200 tabelle. Un vecchio database con molte cattive soluzioni in modo che potessi vedere i vantaggi di Entity Framework su Linq2Sql ma preferirei comunque ridisegnare il database poiché il database è il motore dell'applicazione e se il database è mal progettato e lento quindi la mia applicazione sarà anche lento. L'utilizzo del framework Entity su un database di questo tipo sembra una soluzione rapida per mascherare il modello errato, ma non potrebbe mai mascherare le cattive prestazioni ottenute da tale database.

— terjetyl
fonte

1

Ti manca il punto - anche con piccoli database, potresti voler qualcosa di diverso rispetto a una relazione 1: 1 tra tabelle di database e oggetti codice / dominio. Dipende solo da quanta astrazione vuoi negli oggetti bus / dominio.

— alchemico,

18

Mi sono reso conto che :) Oggi mi piace codificare a mano le mie entità aziendali. Uso ancora Linq2sql ma solo nei miei repository in cui ottengo dati utilizzando Linq2sql e converto le entità linq2sql nelle mie entità aziendali personalizzate. Forse un po 'più di lavoro rispetto all'utilizzo di un or-mapper, ma mi piace comunque mantenere il mio livello aziendale libero da qualsiasi codice specifico di OR-mapper.

— terjetyl,

25

Puoi trovare un buon confronto qui:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

— Omer K
fonte

2

Alcune cose nella risposta non sono corrette. Un EDMX non è necessario se si utilizza Code First. E non capisco come entra in gioco DI quando si utilizza Code First.

— Maarten,

1

Inoltre, Linq to SQL può popolare un DB dalle classi del modello. Non sono sicuro che possa anche generare il DB stesso, ma la generazione dello schema e delle tabelle rientra nelle capacità di Linq per SQL.

— Tom Lint,

Grazie per la risposta, penso che si possa usare sqlmetal.exe docs.microsoft.com/en-us/dotnet/framework/tools/… per generare codice / mapping dal database quando si utilizzaLinq to SQL

— Vinod Srivastav

23

Le risposte qui hanno coperto molte delle differenze tra Linq2Sql ed EF, ma c'è un punto chiave a cui non è stata data molta attenzione: Linq2Sql supporta solo SQL Server mentre EF ha provider per i seguenti RDBMS:

Fornito da Microsoft:

Driver ADO.NET per SQL Server, OBDC e OLE DB

Tramite fornitori di terze parti:

MySQL
Oracolo
DB2
VistaDB
SQLite
PostgreSQL
Informix
U2
Sybase
Synergex
Firebird
Npgsql

per dirne alcuni.

Questo rende EF una potente astrazione di programmazione sul tuo archivio dati relazionale, il che significa che gli sviluppatori hanno un modello di programmazione coerente con cui lavorare indipendentemente dall'archivio dati sottostante. Ciò potrebbe essere molto utile nelle situazioni in cui si sta sviluppando un prodotto che si desidera garantire che interagisca con una vasta gamma di RDBMS comuni.

Un'altra situazione in cui tale astrazione è utile è quella in cui fai parte di un team di sviluppo che lavora con un numero di clienti diversi o diverse unità aziendali all'interno di un'organizzazione e desideri migliorare la produttività degli sviluppatori riducendo il numero di RDBMS che devono diventare familiarità al fine di supportare una vasta gamma di applicazioni diverse su RDBMS diversi.

— Saille
fonte

15

Ho scoperto che non potevo usare più database all'interno dello stesso modello di database quando usavo EF. Ma in linq2sql ho potuto semplicemente aggiungere un prefisso ai nomi dello schema con i nomi del database.

Questo è stato uno dei motivi per cui inizialmente ho iniziato a lavorare con linq2sql. Non so se EF abbia ancora consentito questa funzionalità, ma ricordo di aver letto che era previsto che non lo consentisse.

— Banford
fonte

12

Se il tuo database è diretto e semplice, LINQ to SQL lo farà. Se hai bisogno di entità logiche / astratte in cima alle tue tabelle, scegli Entity Framework.

— Vintana
fonte

4

Entity Framework consente un livello di astrazione della parte superiore del database. Il problema con molti mapper OR oggi (secondo me) è che forniscono un mapping 1 a 1 tra tabelle e classi. Il modello di database non riflette sempre il modo in cui lo pensiamo in termini di modello di business.

— senfo,

Sono uscito dallo spazio. Comunque, in base a quanto detto sopra, direi che la tua risposta non è completa.

— senfo,

7

Penso che questo sia davvero un cattivo consiglio. L2S è buono indipendentemente dalla semplicità o dalla complessità del database. La vera trappola non sta avendo una corretta separazione delle preoccupazioni. Se provi a unire il tuo livello aziendale e il tuo livello di accesso ai dati e usi gli oggetti Linqed up per tutto, troverai L2S limitante. Ma questo è un problema con un design eccessivamente semplicistico e monolitico. L2S è un ottimo DAL, e se consideri l'interrogazione e la persistenza una preoccupazione separata dalle tue regole aziendali, ti risparmierai un sacco di problemi in molte aree nel lungo periodo.

— mattmc3,

1

questo non mi dice niente. Cosa è semplice nei tuoi termini?

— Positivo

1

e cosa intendi come esempio per un bisogno di "logico / astratto". Sì, so cos'è l'astrazione, ma un esempio nel tuo contesto, per favore ... per spiegarmi esattamente cosa stai dicendo ... descrivilo, non limitarmi a darmi un gergo generale ... è tutto relativo all'oratore che dice quelle parole quindi non ho idea di cosa intendi con questo.

— Positivo

8

Né supporta ancora i tipi di dati univoci di SQL 2008. La differenza dalla mia prospettiva è che Entity ha ancora la possibilità di costruire un modello attorno al mio tipo di dati geografici in una versione futura e che Linq to SQL, essendo abbandonato, non lo farà mai.

Mi chiedo che succede con nHibernate o OpenAccess ...

— John Dunagan
fonte

3

Tipi di dati spaziali di SQL Server 2008 (Open Geospatial Consortium OGS) supportati da Entity Framework 5. Sono supportati anche altri provider (Devart per Oracle). Vedere msdn.microsoft.com/en-us/data/dn194325 .

— subsci

6

Penso che se hai bisogno di sviluppare qualcosa di veloce senza cose strane nel mezzo, e hai bisogno della possibilità di avere entità che rappresentano i tuoi tavoli:

Linq2Sql può essere un buon alleato, usandolo con LinQ si scatena un grande tempismo di sviluppo.

— MRFerocius
fonte

4

"niente cose strane nel mezzo", ok cosa intendi con questo. Esempio di "cosa strana nel mezzo"

— Positivo

Sarebbe bello modificare o eliminare questa risposta, non è più utile per lo sviluppo moderno e può portare le persone sulla strada sbagliata.

— Giulio Caccin,

6

Sto lavorando per un cliente che ha un grande progetto che utilizza Linq-to-SQL. All'inizio del progetto era la scelta più ovvia, in quanto Entity Framework mancava in quel momento di alcune funzionalità importanti e le prestazioni di Linq-to-SQL erano molto migliori.

Ora EF si è evoluto e Linq-to-SQL non ha supporto asincrono, il che è ottimo per servizi altamente scalabili. A volte abbiamo oltre 100 richieste al secondo e nonostante abbiamo ottimizzato i nostri database, il completamento della maggior parte delle query richiede ancora alcuni millisecondi. A causa delle chiamate sincrone al database, il thread è bloccato e non disponibile per altre richieste.

Stiamo pensando di passare a Entity Framework, esclusivamente per questa funzione. È un peccato che Microsoft non abbia implementato il supporto asincrono in Linq-to-SQL (o open-source, quindi la community potrebbe farlo).

Addendum dicembre 2018: Microsoft si sta muovendo verso .NET Core e Linq-2-SQL non è supportato su .NET Core, quindi è necessario passare a EF per assicurarsi di poter migrare a EF.Core in futuro.

Ci sono anche alcune altre opzioni da considerare, come LLBLGen . È una soluzione ORM matura che esiste già da molto tempo ed è stata dimostrata più a prova di futuro rispetto alle soluzioni di dati MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

— Ramon de Klein
fonte

2

LINQ to SQL

È un provider che supporta solo SQL Server. È una tecnologia di mappatura per mappare le tabelle del database di SQL Server su oggetti .NET. È il primo tentativo di Microsoft in un ORM - Mappatore relazionale di oggetti.

LINQ to Entities

È la stessa idea, ma utilizzando Entity Framework in background, come ORM - sempre da Microsoft, supporta più database il vantaggio principale del framework di entità è che lo sviluppatore può lavorare su qualsiasi database senza bisogno di imparare la sintassi per eseguire qualsiasi operazione su diversi database diversi

Secondo la mia esperienza personale, Ef è migliore (se non si ha idea di SQL) le prestazioni in LINQ sono leggermente più veloci rispetto alla ragione EF, linguaggio LINQ scritto in lambda.

— Umang Patwa
fonte