Pensi che sia vantaggioso passare a Entity Framework?

Question

Con LINQ to SQL molto probabilmente non otterremo lo stesso sviluppo attivo di Entity Framework, pensi che sia meglio passare a Entity Framework?

Personalmente ho trovato che EF è molto goffo e difficile da usare rispetto a LINQ to SQL che sembra molto naturale.

EDIT: ho recentemente pubblicato un articolo sul mio blog sui miei sentimenti verso questo potenziale decisione ...

ADO.NET v LINQ to SQL

Answer 1

IMO, non al momento.

È chiaro (in particolare da recent announcements) che EF è disponibile per alcune revisioni pesanti poiché lo scenario "thunderdome" viene riprodotto tra LINQ-to-SQL ed EF. Qualunque cosa accada, EF (tra qualche anno) sarà quasi certamente diverso dall'EF oggi. O certamente "abbastanza diverso" ;-p

Come tale, la mia opinione è: bastone con semplice. E semplice LINQ-to-SQL.

Non vedo molti vantaggi nell'apprendere un sistema notoriamente complesso se so che cambierà molto presto.

E io sono al 100% con voi su LINQ to SQL ;-p

Se avevo bisogno di qualcosa di più di LINQ to SQL in questo momento, mi piacerebbe guardare in NHibernate o forse LLBLGen Pro.

(modifica - come aggiornamento, la mia posizione si è ammorbidita un po ', e herehere - ma sto ancora utilizzando LINQ to SQL come mio strumento primario; inoltre - LINQ to SQL isn't quite dead yet; -p).

Answer 2

Parecchi sviluppatori esperti hanno fornito "ADO .NET Entity Framework Vote of No Confidence" come descritto ulteriormente here.

Penso che ci aspettiamo che sia migliorato in modo significativo in .Net 4.0 dal team di ADO.Net.

Ed ecco alcuni video dal PDC recente.

Answer 3

Per la cronaca, qualche esitazione sul futuro di LINQ to SQL è stata espressa qui:

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

Answer 4

Sono d'accordo con Marc Gravell. Forse quando viene rilasciata la prossima versione di Entity Framework (.net 4.0/VS2010) ci sarà un vantaggio nell'utilizzo di EF, e sarà probabilmente molto diverso dall'attuale versione di EF.

Fino ad allora, almeno, eviterò EF come la piaga per qualsiasi cosa, oltre a test/codice sperimentale che non arriverà mai alla produzione.

Il EF msdn forum è piena di esempi per spiegare perché EF non è pronto per prime-time, ma c'è one particular example che è un chiaro vincitore - quello che sarebbe normalmente un semplice cinque query di tabella (10-15 righe di SQL) diventa >1500 lines of SQL quando si utilizza EF ed il controllo EntityDataSource:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1

http://paste-it.net/public/q6ed5c2/

e per quanto riguarda il futuro di EF - con Microsoft di history of changing direction sulle grandi cose strategiche durante la notte, chissà se loro attuale "s obiettivo trategico "con EF si realizzerà tra un paio di anni da oggi ..? Di sicuro non ci scommetterei. Vedere:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623

Answer 5

LINQ to SQL non sembra essere un'opzione a meno che non si utilizza SQL Server (o SQL Server Compact), così che era un motivo sufficiente per me per evitarlo e utilizzare EF (volevo usare PostgreSQL).

Ci sono sicuramente abbastanza cose mancanti in v1 di EF che mi farebbe esitare a raccomandarlo. Sembra che la versione 2 dell'EF (quando rilasciata) sarebbe la prima versione che potrebbe essere seriamente raccomandata per il passaggio a.

Answer 6

Se si sta eseguendo lo sviluppo basato su database, EF offre vantaggi reali oggi.

Ho usato sia LINQ to SQL ed EF e ho lavorato attraverso le molte piccole frustrazioni di EF v1.

Tuttavia, l'unica cosa che ha fatto vincere EF v1 per me è il sorprendente aggiornamento dalla procedura guidata del database. Incredibilmente, questo funziona in realtà! Può sembrare banale, ma se stai progettando il database al primo posto, vuoi fare affidamento sugli strumenti per creare le tue classi per te e non vuoi dover rigenerare l'intero modello solo per fare un cambiamento.

Questo solo rende EF v1 la mia scelta. Suggerisco di ignorare le funzionalità avanzate di EF v1: non è neanche lontanamente utilizzabile come l'ambiziosa piattaforma che intende essere.

Soddisfate del clunkiness di EF v1 e sarete nella migliore posizione per il futuro.

Pete.

Answer 7

Ho completato alcuni progetti MVC ora in produzione con L2SQL sotto il cofano e l'ho trovato piuttosto piacevole da usare. Ora sto imbarcando in un nuovo progetto e ho deciso di scriverlo usando EF e L2EF dati gli articoli citati in precedenza che proclamavano la morte di L2SQL. Dopo solo un paio di giorni ho deciso di tornare su L2SQL. Le cose semplici come dover impostare le chiavi esterne per gli inserti utilizzando la sintassi terribile mostrata di seguito o le ricerche non necessarie mi hanno scioccato.

foo.Foreign_TypeReference.EntityKey = 
    new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId); 

Piuttosto che:

foo.Foreign_Type_Id = ForeignTypeId; 

non credo che sarà così difficile da porto L2SQL ad una futura versione di EF come L2SQL ha un sottoinsieme delle funzionalità (anche se meglio implementato). Le poche cose che L2SQL ha che L2EF non è, per esempio Single() e SingleOrDefault(), possono essere migrate in EF creando alcuni metodi di estensione. Penso che ci vorrà molto meno tempo per far funzionare il sistema usando L2SQL e poi portarlo più tardi quando EF non è così maleodorante.

Answer 8

Recentemente, ho dovuto ricercare quale progetto ORM dovrebbe usare. All'inizio - ha provato L2S. Non era affatto male, ma è già obsoleto (MS non lo supporta più), ecco perché ho iniziato a controllare L2E. Sto bene con il codice generato, ma creare viste false, entità e mappature tra di loro solo per rendere disponibile la stored procedure e non per riempire tutti i campi di entità è stato per me eccessivo. E volevo separare il mio livello dataaccess, quindi - ho dovuto mappare i dati da oggetti generati a quelli che ho creato.

Mi ci sono volute alcune ore di esperimenti con NHibernate + Fluent NHibernate + LINQ su NHibernate
da utilizzare con questa combinazione.