ADO.NET Entity Framework o ADO.NET

Question

Sto avviando un nuovo progetto basato su ASP.NET e server Windows.

L'applicazione è progettata per essere abbastanza grande e serve una grande quantità di clienti che estrae e aggiornano l'alta frequenza. cambiare i dati.

Ho già creato progetti con Linq-To-Sql o con Ado.Net.

Il mio piano per questo progetto è utilizzare VS2010 e il nuovo framework EF4.

• Sarebbe bello sentire altre opzioni programmatori sullo sviluppo con Entity Framework

• pro e contro da precedenti esperienza?

• Pensi che EF4 sia pronto per la produzione ?

• Devo correre il rischio o semplicemente attaccare con un semplice vecchio ADO.NET buono?

Answer 1

Se EF4 è veramente pronto per la produzione è un po 'difficile da dire poiché non è ancora stato rilasciato ufficialmente .... ma tutte le esperienze preliminari e le segnalazioni sembrano indicare che è abbastanza buono.

Tuttavia: è necessario prendere in considerazione ciò che EF sta cercando di risolvere; si tratta di un approccio a due livelli, un layer si associa allo schema di archiviazione fisica nel database (e supporta più backend) e il secondo livello è il modello concettuale a cui si programma. E, naturalmente, c'è bisogno di una mappatura tra questi due strati.

Quindi EF4 è ottimo se si dispone di un numero elevato di tabelle, se si dispone di più backend per supportare, se è necessario essere in grado di mappare uno schema fisico in uno schema concettuale diverso e così via. È ottimo per applicazioni di livello aziendale complesse.

MA questo ha un costo: quegli strati aggiuntivi hanno un impatto su prestazioni, complessità, manutenibilità. Se hai bisogno di queste funzionalità, sarai felice di pagare quel prezzo, senza fare domande. Ma hai bisogno di quello ??

Certo, si potrebbe tornare al dritto ADO.NET - ma vuoi davvero giocherellare con DataTables, DataRows e costrutti di nuovo Row["RowName"] ancora una volta ?? VERAMENTE???

Quindi il mio consiglio sarebbe questo:

• se avete bisogno solo di SQL Server come back-end
• se si dispone di una mappatura abbastanza semplice e lineare della tabella di un database a un oggetto un'entità nel modello

quindi: utilizzare Linq-to-SQL! Perchè no?? È ancora totalmente supportato da Microsoft in .NET 4 - diamine, lo hanno anche fatto bugfixes and added a few bits and pieces - è veloce, efficiente, è snello e cattivo - quindi perché no?

Answer 2

EF 4 è ora più simile a LINQ to SQL, nei buoni modi; ha le chiavi FK proprio nell'oggetto, ha aggiunto metodi proprio negli insiemi di oggetti e molte altre belle funzionalità. Il progettista è molto migliorato e il vantaggio principale è che funziona con SQL e Oracle, e forse con altri (purché il provider lo supporti) anziché LINQ su SQL con solo SQL Server.

EF è il futuro; i servizi dati ADO.NET sono un servizio Web aggiuntivo, in più supporta la generazione POCO e T4 e tutte le nuove funzionalità supporteranno questo (LINQ a SQL è solo manutenzione e i set di dati non otterranno più alcuna modifica).

HTH.

Answer 3

Il mio consiglio è usare entrambi. All'inizio pensavo di usare solo linq su sql e non dover mai più toccare ado.net (cosa mi ha reso felice lol).

Ora sto usando entrambi perché alcune cose da linq a sql (e qualsiasi ORM come EF) non possono fare. Ho dovuto fare alcuni inserimenti di massa e l'ho fatto prima con linq a sql e per fare 500 record ci sono voluti più di 6 minuti (2 minuti per il resto delle regole di validazione stava inserendo nel db).

ho cambiato in sql copia di massa e ora è giù per secondi 2min e 4 (4 secondi per fare tutti gli inserti)

Ma come marc_s detto che non volevamo a casaccio con DataTable, DataRow, e non tipizzato Row ["RowName"].

Supponiamo che la mia tabella fosse lunga come 10 colonne e denominata Tabella A. Ciò che ho fatto è stato che ho usato linq in sql e creato una classe Table A (nuovo oggetto TableA()) e popolato con dati. Quindi passerei questo oggetto a un metodo che ha creato il datarow.

Quindi linq to sql mi ha salvato un po 'di tempo perché probabilmente avrei creato una classe in quanto non avrei voluto passare in 10 parametri nel metodo che rende la riga di dati. Sento anche che restituisce un po 'di tipicità dato che devi passare nell'oggetto giusto per usare quel metodo, quindi meno possibilità di trasmettere dati sbagliati.

Infine è ancora possibile utilizzare linq to sql per chiamare stored procedure e che è come una riga di codice.

Quindi vorrei usare entrambi quando mai si nota che linq to sql (o nel proprio caso EF) è lento, quindi basta scrivere un SP e chiamarlo tramite EF. Se hai bisogno di fare direttamente ado.net valutare cosa devi fare, forse puoi usare EF per la maggior parte del codice (quindi puoi almeno lavorare con gli oggetti) e solo per quella piccola parte ado.net di quello che ho fatto con sql bulk copy.