Pensi che sia vantaggioso passare a Entity Framework?

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: Recentemente ho pubblicato un articolo sul mio blog sui miei sentimenti verso questa potenziale decisione …

ADO.NET v LINQ a SQL

IMO, non al momento.

È chiaro (soprattutto da recenti annunci ) che EF ha delle revisioni importanti, in quanto lo scenario ” thunderdome ” si svolge 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

In quanto tale, il mio punto di vista è: bastone con semplice. E semplice LINQ-to-SQL.

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

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

Se avessi bisogno di qualcosa di più rispetto a LINQ-to-SQL adesso, guarderei NHibernate o forse LLBLGen Pro .

( modifica – come aggiornamento, la mia posizione si è attenuata un po ‘, qui e qui – ma sto ancora utilizzando LINQ-to-SQL come strumento principale, inoltre LINQ-to-SQL non è ancora completamente morto ; p).

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 syntax 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 penso che sarà così difficile trasferire L2SQL in una versione futura di EF poiché L2SQL ha un sottoinsieme della funzionalità (sebbene 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.

Se stai facendo uno sviluppo basato su database, EF ha oggi dei veri vantaggi.

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

Tuttavia, l’unica cosa che ha fatto vincere EF v1 per me è l’ aggiornamento sorprendentemente buono della procedura guidata del database . Incredibilmente, funziona davvero ! 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 da 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.

Sopporta il clunkiness di EF v1 e sarai nella migliore posizione per il futuro.

Pete.

Devo essere d’accordo con Marc Gravell. Forse quando verrà 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 forum msdn di EF è pieno di esempi sul motivo per cui EF non è pronto per il prime time, ma c’è un esempio particolare che è un chiaro vincitore – cosa sarebbe normalmente una semplice query di cinque tabelle (10-15 righe di SQL) diventa > 1500 righe di SQL quando si utilizza EF e 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 la storia di Microsoft di cambiare direzione durante le grandi cose strategiche durante la notte, chissà se il loro attuale “objective strategico” con EF si avvererà 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

Per la cronaca, alcune esitazioni sul futuro di LINQ to SQL sono state espresse qui:

LINQ to SQL DOA?

Microsoft ha davvero ucciso LINQ in SQL?

LINQ to SQL non sembra essere un’opzione a meno che non si usi SQL Server (o SQL Server compact), quindi è stato sufficiente per me evitarlo e utilizzare EF (volevo usare PostgreSQL).

Ci sono sicuramente abbastanza cose mancanti nella v1 di EF che mi farebbero 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.

Un bel po ‘di sviluppatori esperti hanno dato ” Voto di sicurezza di ADO .NET Entity Framework ” come discusso più avanti qui .

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

Ed ecco alcuni video dal recente PDC.

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, entity framework e mappature tra di loro solo per rendere disponibile la stored procedure e non per riempire tutti i campi di quadro è 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
attenersi a questa combinazione.