Entity Framework vs Direct Data Access

Question

Ho sempre utilizzato l'accesso diretto ai dati per gestire gli oggetti in passato (eseguendo manualmente una query e associando i risultati in oggetti dati). So che Microsoft sta attualmente spingendo EF per i propri clienti da utilizzare per l'interrogazione di oggetti dati.

ho un paio di domande per la comunità rispetto a questo: -

• Se si dispone di un database complesso, vale a dire un paio di centinaia di tavoli, una discreta quantità di stored procedure, viste, tutto è in 3NF. Il peso della gestione di due schemi (una mappatura dello schema EF locale e un DB) vale la pena?

• Una volta che si inizia ad aumentare l'accesso ai dati, come si confronta il caching sui due? So che nell'accesso diretto è possibile implementare qualsiasi forma di memorizzazione nella cache che si desidera, EF consente qualcosa di simile?

• Data la storia di Microsoft di eliminare i prodotti dopo averli pesantemente spinti e costringendo le persone a scrivere per loro (SQL-NS, Linq-to-Sql), quanto è probabile che succeda a EF?

Come ho detto Attualmente sto usando pesantemente Accesso diretto al momento, ma considerando una migrazione (cioè con nuove interrogazioni andando avanti, non tornando indietro su di loro tutto solo ancora), ed è stato alla ricerca di consigli dal resto della comunità sulle loro opinioni.

Answer 1

Se si dispone di un database complesso, vale a dire un paio di centinaia di tavoli, un discreta quantità di stored procedure, viste, tutto è in 3NF. l'onere della gestione di due schemi (uno schema di schema EF locale e un DB) vale la pena?

È possibile utilizzare strumenti automatici per mantenere aggiornato lo schema EF, quindi non è poi così male.

Una volta che si inizia ad aumentare l'accesso ai dati, come si confronta il caching su i due? So che in Accesso diretto è possibile implementare qualsiasi forma di memorizzazione nella cache desiderata, EF consente qualcosa di simile?

Per quanto ne so, sì.

Data la storia di Microsoft di uccidere prodotti dopo pesantemente spingendoli e convincere la gente a scrivere per loro (SQL-NS, LINQ-to-SQL) Procedura likley è questo accada a EF?

Questa domanda è troppo ipotetica.

Il problema che sto avendo con EF è la sua prestazione. Sì, si ottiene uno sviluppo rapido, ma si scambiano le prestazioni. Con EF è davvero facile scrivere un codice brutto e lento e se non sai al 100% cosa stai facendo, potresti finire con problemi di prestazioni gravi in ​​seguito (specialmente se hai a che fare con centinaia di tabelle) .

Quello che suggerirei è provare alcuni framework Micro-ORM, come Dapper o Massive. Non sacrifichi così tanto rendimento, ma è più semplice da mantenere rispetto all'approccio tradizionale di Ado.net.

Ma hey, sono solo io, puoi amare EF.

Answer 2

La cosa da tenere a mente con EF o con qualsiasi altro strumento ORM è che converte semplicemente qualcosa (alberi di espressione Linq nel caso di EF e Linq2Entities) in istruzioni SQL. Dato che c'è un ulteriore livello di astrazione e analisi, sarà sempre più lento l'interrogazione diretta. Tuttavia, di solito è più facile per uno sviluppatore utilizzare un ORM. Fortunatamente, la maggior parte degli ORM (non sono sicuro di EF in particolare) fornisce un modo di eseguire ancora le query direttamente quando necessario.

Si dice di avere un database "complicato" e che di solito significa avere query complicate. Questo è qualcosa che a Linq non piace molto. Ad esempio se si finisce per avere query che si uniscono a 13 tabelle, e quasi ogni colonna restituita viene passata a una funzione db e ha un sacco di istruzioni caso e un gruppo di sottoseleziona, quindi diventa quasi impossibile tradurre in Linq . La cosa più semplice da fare è racchiudere quella complessità in una vista e usare EF per interrogare semplicemente la vista.

Sul lato positivo, EF fornisce allo sviluppatore intellisense, poiché le classi reali sono costruite per simulare il DB. A seconda di come sono strutturati i tuoi oggetti EF, puoi impostare il tuo progetto in modo che le classi siano tutte generate dal DB, quindi se qualcuno modifica lo schema DB o cambia un tipo di dati di colonna, il tuo codice C# non più compilato. Con le query SQL dirette tradizionali, non lo si trova mai fino al runtime (o al tempo di test dell'integrazione).

È tutto un compromesso ... IMO la cosa migliore da fare è provare entrambi e vedere quale ti piace di più, o progettare una soluzione in modo tale da fornire entrambe le opzioni. Nell'ultima app su cui lavoravo, avevo una classe "factory di database" (modello factory) che le altre classi di accesso ai dati avrebbero usato, e potevano chiedere alla fabbrica un semplice vecchio oggetto Command ADO.NET, o chiedere il Oggetto ORM (il contesto nel caso EF, ma stavo usando SubSonic quindi era un'implementazione IQueryable). In questo modo puoi eseguire query "semplici" tramite EF e query "complesse" in SQL.

Answer 3

Il vantaggio principale di EF rispetto all'accesso diretto ai dati è la produttività degli sviluppatori.

Pochissimi sviluppatori scrivono codice di assemblaggio più, lasciamo che sia il compilatore a generarlo. Man mano che gli strumenti come EF miglioreranno, li useremo di più e smetteremo di scrivere SQL.

Tuttavia, a volte è necessario il controllo aggiuntivo per ottenere le prestazioni richieste, quindi potrebbe essere necessario scrivere un codice SQL. Proprio come c'è ancora qualche codice Assembly in fase di scrittura.

Non esiste un valore aziendale per la conversione di una soluzione che funziona. Potresti provare EF per un nuovo sviluppo.