Entity Framework e LINQ to SQL

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

Domanda

Ora che è stato rilasciato .NET v3.5 SP1 (insieme a VS2008 SP1), ora abbiamo accesso al framework delle 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?Se è così, quali vantaggi comporta?Cosa può fare che LINQ to SQL non può fare da solo?

È stato utile?

Soluzione

LINQ to SQL supporta solo il mapping 1 a 1 di tabelle, viste, sproc e funzioni del database disponibili in Microsoft SQL Server.Si tratta di un'ottima API da utilizzare per la creazione di un rapido accesso ai dati in 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 di modelli di dominio a oggetti e le loro relazioni con molti diversi provider di dati ADO.Net.Pertanto, è possibile combinare e abbinare diversi fornitori di database, server applicativi o protocolli 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

Altri suggerimenti

Penso che la risposta rapida e sporca sia questa

  • LINQ to SQL è il modo semplice e veloce per farlo.Ciò significa che inizierai a lavorare più velocemente 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 più flessibilità se stai lavorando su qualcosa di più grande.

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

Matt Warren descrive [da Linq a SQL] come qualcosa che "non avrebbe mai dovuto nemmeno esistere". In sostanza, doveva solo essere stand-in per aiutarli a sviluppare LINQ fino a quando il vero orm non era pronto.

...

La portata di Entity Framework ha causato il mancato rispetto della scadenza di .NET 3.5/Visual Studio 2008.È stato completato in tempo per il ".NET 3.5 Service Pack 1", sfortunatamente chiamato ".NET 3.5 Service Pack 1", che era 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 gli scenari relazionali LINQ to.

Ci sono una serie di differenze evidenti delineate nell'articolo pubblicato da @lars, ma la risposta breve è:

  • L2S è strettamente accoppiato: proprietà dell'oggetto a un campo specifico del database o, più correttamente, mappatura degli oggetti a 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 M-M
  • EF potrà scegliere come target qualsiasi provider di dati ADO.NET

La premessa originale era che L2S sta per Rapid Development ed EF per più applicazioni "enterprisey" a più livelli, ma questo sta vendendo L2S un po' a corto.

LINQ toSQL

  1. Origine dati omogenea:server SQL
  2. Consigliato per piccoli progetti solo dove la struttura dei dati è ben progettata
  3. È possibile modificare la mappatura senza ricompilare con SqlMetal.exe
  4. .dbml (linguaggio di markup del database)
  5. Mappatura uno a uno tra tabelle e classi
  6. Supporta TPH eredità
  7. Non supporta tipi complessi
  8. Approccio incentrato sullo storage
  9. Visualizzazione incentrata sul database di un database
  10. Creato dal team C#
  11. Supportato ma non previsti ulteriori miglioramenti

Struttura delle entità

  1. Origine dati eterogenea: Supporta molti fornitori di dati
  2. Consigliato per tutti i nuovi progetti tranne:
    • quelli piccoli (LINQ to SQL)
    • quando l'origine dati è un file flat (ADO.NET)
  3. La mappatura può essere modificata senza ricompilare durante l'impostazione del modello e della mappatura dei file Elaborazione artefatto metadati su Copia nella directory di output
  4. .edmx (Entity Data Model) che contiene:
    • SSDL (linguaggio di definizione dello schema di archiviazione)
    • CSDL (linguaggio di definizione dello schema concettuale)
    • MSL (linguaggio delle specifiche di mappatura)
  5. Mappature uno-a-uno, uno-a-molti e molti-a-uno tra tabelle e classi
  6. Supporta l'ereditarietà:
    • TPH (tabella per gerarchia)
    • TPT (tabella per tipo)
    • TPC (Tabella per classe di calcestruzzo)
  7. Supporta tipi complessi
  8. Approcci code-first, model-first e storage-first
  9. Visualizzazione incentrata sull'applicazione di un database
  10. Creato dal team di SQL Server
  11. Il futuro delle API dati Microsoft

Guarda anche:

La mia esperienza con Entity Framework è stata tutt'altro che eccezionale.Innanzitutto, devi ereditare dalle classi base EF, quindi saluta i POCO.Il tuo progetto dovrà essere attorno all'EF.Con LinqtoSQL ho potuto utilizzare i miei oggetti aziendali esistenti.Inoltre, non è previsto il caricamento lento, devi implementarlo tu stesso.Esistono alcune soluzioni alternative per utilizzare POCO e caricamento lento, ma IMHO esistono perché EF non è ancora pronto.Ho intenzione di tornarci dopo la 4.0

Ho trovato un'ottima risposta Qui che spiega quando usare what in parole semplici:

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

  • Linq-To-Sql -Usa questo framework se si prevede di modificare una relazione individuale dei tuoi dati nel livello di presentazione.Significa che non si prevede di combinare i dati da più di una tabella in una vista o pagina.

  • Struttura delle entità - Utilizzare questo framework se si prevede di combinare i dati da più di una tabella nella vista o nella pagina.Per rendere questo più chiaro, i termini di cui sopra sono specifici per i dati che verranno manipolati nella tua vista o pagina, non solo visualizzati.Questo è importante da capire.

Con il framework di entità sei in grado di "unire" i dati presentati insieme per presentarsi al livello di presentazione in un modulo modificabile, e quindi quando tale modulo viene inviato, EF saprà come aggiornare tutti i dati dalle varie tabelle.

Probabilmente ci sono ragioni più accurate per scegliere EF su L2S, ma questo sarebbe probabilmente il più semplice da capire.L2S non ha la capacità di unire i dati per la presentazione della visualizzazione.

La mia impressione è che il tuo database sia piuttosto enorme o progettato molto male se Linq2Sql non soddisfa le tue esigenze.Ho circa 10 siti Web sia più grandi che più piccoli, tutti utilizzando Linq2Sql.Ho cercato molte volte il framework Entity, ma non riesco a trovare un buon motivo per utilizzarlo su Linq2Sql.Detto questo, provo a utilizzare i miei database come modello, quindi ho già una mappatura 1 a 1 tra modello e database.

Nel mio attuale lavoro abbiamo un database con oltre 200 tabelle.Un vecchio database con molte soluzioni sbagliate, quindi ho potuto vedere i vantaggi di Entity Framework rispetto a Linq2Sql, ma preferirei comunque riprogettare il database poiché il database è il motore dell'applicazione e se il database è mal progettato e lento, allora 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 un database di questo tipo.

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

Fornito da Microsoft:

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

Tramite fornitori terzi:

  • MySQL
  • Oracolo
  • DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • Uccello di fuoco
  • Npgsql

per dirne alcuni.

Ciò rende EF una potente astrazione di programmazione sull'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 in situazioni in cui si sta sviluppando un prodotto di cui si desidera garantire l'interoperabilità con un'ampia gamma di RDBMS comuni.

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

Ho scoperto che non potevo utilizzare più database all'interno dello stesso modello di database quando utilizzavo EF.Ma in linq2sql potrei semplicemente anteponendo ai nomi dello schema i nomi dei database.

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

Se il tuo database è diretto e semplice, LINQ to SQL andrà bene.Se hai bisogno di entità logiche/astratte sopra le tue tabelle, scegli Entity Framework.

Nessuno dei due supporta ancora i tipi di dati SQL 2008 univoci.La differenza dal mio punto di vista è che Entity ha ancora la possibilità di costruire un modello attorno al mio tipo di dati geografico in una versione futura e Linq to SQL, essendo abbandonato, non lo farà mai.

Mi chiedo cosa succede con nHibernate o OpenAccess...

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 le tue tabelle:

Linq2Sql può essere un buon alleato, utilizzarlo con LinQ scatena un ottimo timing di sviluppo.

Sto lavorando per un cliente che ha un grande progetto che utilizza Linq-to-SQL.Quando il progetto è iniziato è stata la scelta più ovvia, perché a quel tempo Entity Framework mancava di alcune funzionalità importanti e le prestazioni di Linq-to-SQL erano molto migliori.

Ora EF si è evoluto e Linq-to-SQL è privo di supporto asincrono, il che è ottimo per servizi altamente scalabili.A volte riceviamo più di 100 richieste al secondo e, nonostante abbiamo ottimizzato i nostri database, il completamento della maggior parte delle query richiede ancora diversi 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 funzionalità.È un peccato che Microsoft non abbia implementato il supporto asincrono in Linq-to-SQL (o lo abbia reso open source, in modo che la comunità potesse farlo).

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

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

LINQ to SQL e Entity Framework sembrano simili in superficie.Entrambi forniscono query LINQ su un database utilizzando un modello di dati.

Linq a SQL si è evoluto dal progetto LINQ, che è uscito dal team lavorando con lo sviluppo del linguaggio. Mentre il framework entità era un progetto del team di programmabilità dei dati ed era focalizzato sul linguaggio di entità SQL.Microsoft non ha alcuna intenzione di deprezzare LINQ to SQL.

LINQ to SQL fa ancora parte di ADO.NET mentre Entity Framework ha un'API separata.Il framework Entity è la versione superiore di LINQ to SQL. Il framework Entity utilizza Entity Data Model per collegare l'applicazione e l'archivio dati.È l'Entity Data Model, o EDM, che fornisce la definizione del tuo schema concettuale nonché le informazioni sullo schema del database necessarie per interagire con il database e infine uno schema di mappatura che si collega a due.

Ecco alcune attività eseguite da Entity Framework (modello dati Entity).

• Genera automaticamente le classi dal modello e aggiorna tali classi dinamicamente ogni volta che il modello cambia.

• Si occupa di tutta la connettività del database in modo che gli sviluppatori non siano gravati dalla necessità di scrivere molto codice per interagire con il database.

• Fornisce la sintassi comune delle query per interrogare il modello, non il database, quindi traduce queste query in query che il database può comprendere.

• Fornisce un meccanismo per il monitoraggio delle modifiche agli oggetti del modello in quanto vengono utilizzati nelle applicazioni e gestisce gli aggiornamenti al database.

Linq-to-SQL

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

Linq-to-Entities

È la stessa idea, ma utilizzando Entity Framework in background, come ORM - sempre di Microsoft, supporta più database Il vantaggio principale di Entity Framework è 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 hai idea delle prestazioni SQL) in LINQ è un po 'più veloce rispetto alla lingua Linq di EF scritta in lambda.

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