.net run - Entity Framework vs LINQ to SQL




command code (15)

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 un ORM, qual è la differenza?

Per come l'ho capito, Entity Framework (quando usato con LINQ to Entities) è un "fratello maggiore" di LINQ to SQL? Se questo è il caso, quali vantaggi ha? Cosa può fare che LINQ to SQL non può fare da solo?


Answers

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

LINQ to SQL si è evoluto dal progetto LINQ, che è uscito dal team di lavoro con lo sviluppo del linguaggio. Mentre The Entity Framework era un progetto del team di Programmabilità dei dati ed era incentrato sul linguaggio Entity SQL. Microsoft non ha intenzione di privare LINQ to SQL.

LINQ to SQL è ancora la parte di ADO.NET mentre il framework Entity ha API separate. Entity framework è la versione superiore di LINQ to SQL.Entity framework utilizza Entity Data Model per eseguire il bridging tra l'applicazione e l'archivio dati. È il modello di dati di entità, o EDM, che fornisce la definizione del proprio 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 di dati Entity).

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

• Si prende cura di tutta la connettività del database in modo che gli sviluppatori non siano gravati dal dover scrivere molto codice per interagire con il database.

• Fornisce sintassi di query comune per l'interrogazione del modello, non del database, quindi traduce queste query in query che il database può comprendere.

• Fornisce un meccanismo per tenere traccia delle modifiche agli oggetti del modello man mano che vengono utilizzate nelle applicazioni e gestisce gli aggiornamenti del database.


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

Matt Warren descrive [LINQ to SQL] come qualcosa che "non avrebbe mai nemmeno dovuto esistere". Essenzialmente, si supponeva che fosse in piedi per aiutarli a sviluppare LINQ fino a quando il vero ORM non fosse pronto.

...

La scala di Entity Framework gli ha fatto perdere la scadenza .NET 3.5 / Visual Studio 2008. È stato completato in tempo per il nome sfortunatamente ".NET 3.5 Service Pack 1", che era più simile a una versione principale di 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 agli scenari relazionali.


Ci sono un certo numero di ovvie differenze delineate in quell'articolo pubblicato da @lars, ma la risposta breve è:

  • L2S è strettamente accoppiato - la proprietà dell'oggetto a un campo specifico del database o più correttamente il mapping dell'oggetto a uno schema di database specifico
  • L2S funzionerà solo con SQL Server (per quanto ne so)
  • EF consente di associare una singola classe a più tabelle
  • EF gestirà le relazioni MM
  • EF avrà la possibilità di indirizzare qualsiasi fornitore di dati ADO.NET

La premessa originale era che L2S è per Rapid Development e EF per più applicazioni "di livello enterprise", ma che sta vendendo L2S in breve.


La mia esperienza con Entity Framework è stata meno che stellare. Per prima cosa, devi ereditare dalle classi base EF, quindi saluta gli POCO. Il tuo disegno dovrà essere intorno all'EF. Con LinqtoSQL potrei usare i miei oggetti di business esistenti. Inoltre, non vi è alcun caricamento lazy, è necessario implementarlo da soli. Ci sono alcuni lavori in giro per usare POCO e il caricamento lento, ma esistono IMHO perché EF non è ancora pronto. Ho intenzione di tornare ad esso dopo la 4.0


Penso che se hai bisogno di sviluppare qualcosa di veloce senza strane cose nel mezzo, e hai bisogno della possibilità di avere entità che rappresentano le tue tabelle:

Linq2Sql può essere un buon alleato, usarlo con LinQ scatena una grande tempistica di sviluppo.


Ho trovato una risposta molto buona here che spiega quando usare ciò in parole semplici:

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

  • Linq-To-Sql : utilizzare questo framework se si intende modificare una relazione uno a uno dei dati nel livello di presentazione. Significa che non hai intenzione di combinare i dati di più di una tabella in una vista o pagina.

  • Entity Framework : utilizzare questo framework se si intende combinare i dati di più tabelle nella vista o nella pagina. Per renderlo più chiaro, i termini di cui sopra sono specifici per i dati che verranno manipolati nella vista o nella pagina, non solo visualizzati. Questo è importante da capire.

Con Entity Framework è possibile "unire" i dati presentati per presentare al livello di presentazione in un formato modificabile, e quindi quando tale modulo viene inviato, EF saprà come aggiornare TUTTI i dati dalle varie tabelle.

Ci sono probabilmente motivi più accurati per scegliere EF su L2S, ma questo probabilmente sarebbe il più facile da capire. L2S non ha la capacità di unire i dati per la presentazione della vista.



LINQ a SQL

  1. Origine dati omogenea: SQL Server
  2. Consigliato per piccoli progetti solo dove la struttura dei dati è ben progettata
  3. La mappatura può essere modificata senza ricompilare con SqlMetal.exe
  4. .dbml (Database Markup Language)
  5. Mappatura uno-a-uno tra tabelle e classi
  6. Supporta l'eredità TPH
  7. Non supporta tipi complessi
  8. Approccio basato sull'archiviazione
  9. Vista centrata sul database di un database
  10. Creato dal team C #
  11. Supportati ma non ulteriori miglioramenti previsti

Entity Framework

  1. Origine dati eterogenea: supporta molti fornitori di dati
  2. Consigliato per tutti i nuovi progetti tranne:
    • piccoli (LINQ to SQL)
    • quando l'origine dati è un file flat (ADO.NET)
  3. La mappatura può essere modificata senza ricompilare quando si impostano i file modello e di mappatura Processo artefatto metadati da copiare 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 (Mapping Specification Language)
  5. Mappature one-to-one, one-to-many, many-to-one tra tabelle e classi
  6. Supporta l'ereditarietà:
    • TPH (tabella per gerarchia)
    • TPT (tabella per tipo)
    • TPC (Table Per Concrete Class)
  7. Supporta tipi complessi
  8. Approccio basato sul codice, Primo modello, Primo deposito
  9. Vista incentrata sull'applicazione di un database
  10. Creato dal team di SQL Server
  11. Il futuro delle API di dati Microsoft

Guarda anche:


LINQ to SQL supporta solo la mappatura 1 a 1 di tabelle di database, viste, sproc e funzioni disponibili in Microsoft SQL Server. È un'ottima API da utilizzare per la costruzione rapida dell'accesso ai dati a 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 (Object Relational Mapper) API che consente un'ampia definizione di modelli di domini di oggetti e le loro relazioni con diversi fornitori di dati ADO.Net. Di conseguenza, è possibile combinare diversi fornitori di database, server di applicazioni o protocolli per progettare un aggregato di oggetti creati da una varietà di tabelle, fonti, servizi, ecc. ADO.Net Framework è stato rilasciato con .Net Framework 3.5 SP1.

Questo è un buon articolo introduttivo su MSDN: Introduzione di LINQ a dati relazionali


Le risposte qui hanno coperto molte delle differenze tra Linq2Sql e 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.

Ciò 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 in situazioni in cui si sta sviluppando un prodotto che si desidera garantire interoperabilità con una vasta gamma di RDBMS comuni.

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


Sto lavorando per un cliente che ha un grande progetto che utilizza Linq-to-SQL. Quando è stato avviato il progetto, era una scelta ovvia, perché a Entity Framework mancavano alcune funzionalità importanti in quel momento e le prestazioni di Linq-to-SQL erano molto più veloci.

Ora EF si è evoluto e Linq-to-SQL è privo di una funzionalità importante per servizi altamente scalabili e questo è il supporto per le operazioni asincrone. A volte abbiamo più di 100 richieste al secondo e nonostante i nostri database siano stati ottimizzati, la maggior parte delle query richiede ancora diversi millisecondi. A causa delle chiamate al database sincrono, il thread è bloccato e non disponibile per altre richieste.

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


Né ancora supporta i tipi di dati unici di SQL 2008. La differenza dal mio punto di vista è che Entity ha ancora la possibilità di costruire un modello attorno al mio tipo di dati geografici in alcune versioni future, e Linq to SQL, essendo abbandonato, non lo farà mai.

Mi chiedo cosa succede con nHibernate o OpenAccess ...


LINQ to SQL

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

LINQ to Entities

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

Secondo la mia esperienza personale Ef è migliore (se non si ha idea di SQL) le prestazioni in LINQ sono un po 'più veloci rispetto al motivo LINQ linguaggio LINQ scritto in lambda.


La mia impressione è che il tuo database sia piuttosto costoso o mal progettato se Linq2Sql non soddisfa le tue esigenze. Ho circa 10 siti web più grandi e più piccoli che usano Linq2Sql. Ho cercato e Entity framework molte volte ma non riesco a trovare una buona ragione per usarlo su Linq2Sql. Detto questo, cerco di utilizzare i miei database come modello, quindi ho già una mappatura 1 a 1 tra modello e database.

Al mio attuale lavoro abbiamo un database con oltre 200 tabelle. Un vecchio database con molte cattive soluzioni, quindi potrei vedere il vantaggio 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 allora la mia applicazione sarà anche lento. L'utilizzo del framework Entity su un database di questo tipo sembra un quickfix per mascherare il modello errato, ma non potrebbe mai nascondere le cattive prestazioni ottenute da un tale database.


Se si imposta la proprietà AllowsTransparency sulla Window (anche senza impostare alcun valore di trasparenza) il bordo scompare e si può ridimensionare solo tramite il grip.

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="640" Height="480" 
    WindowStyle="None"
    AllowsTransparency="True"
    ResizeMode="CanResizeWithGrip">

    <!-- Content -->

</Window>

Il risultato è simile a:







.net entity-framework linq-to-sql