Quali sono alcuni argomenti CONTRO l'utilizzo di EntityFramework? [chiuso]

31

L'applicazione che sto attualmente costruendo utilizza procedure memorizzate e modelli di classe realizzati a mano per rappresentare oggetti di database. Alcune persone hanno suggerito di utilizzare Entity Framework e sto prendendo in considerazione il passaggio a questo dato che non sono così lontano nel progetto. Il mio problema è che sento che le persone che litigano per EF mi dicono solo il lato positivo delle cose, non il lato negativo :)

Le mie principali preoccupazioni sono:

Vogliamo la convalida lato client utilizzando DataAnnotations e sembra che debba comunque creare i modelli lato client, quindi non sono sicuro che EF risparmierebbe così tanto tempo di programmazione
Vorremmo mantenere le classi il più piccole possibile quando si passa sulla rete e ho letto che l'uso di EF spesso include dati extra che non sono necessari
Abbiamo un livello di database complesso che attraversa più database e non sono sicuro che EF possa gestirlo. Abbiamo un database comune con cose come Utenti, StatusCodes, Tipi, ecc. E più istanze dei nostri database principali per diverse istanze dell'applicazione. Le query SELECT possono e verranno interrogate in tutte le istanze dei database, tuttavia gli utenti possono modificare solo gli oggetti che si trovano nel database su cui stanno attualmente lavorando. Possono cambiare database senza ricaricare l'applicazione.
Le modalità oggetto sono molto complesse e spesso sono coinvolti alcuni join

Gli argomenti per EF sono:

Concorrenza. Non dovrei codificare nei controlli per vedere se il record è stato aggiornato prima di ogni salvataggio
Generazione di codice. EF può generare modelli di classe parziale e POCO per me, tuttavia non sono sicuro che ciò mi farebbe risparmiare molto tempo poiché penso che dovremmo ancora creare modelli lato client per la convalida e alcuni metodi di analisi personalizzati.
Velocità di sviluppo poiché non avremmo bisogno di creare le procedure memorizzate CRUD per ogni oggetto del database

La nostra architettura attuale è costituita da un servizio WPF che gestisce le chiamate al database tramite Stored procedure parametrizzate, oggetti POCO che vanno al / dal servizio WCF e dal client WPF e lo stesso client desktop WPF che trasforma i POCO in modelli di classe ai fini della convalida e Associazione dati.

Quindi la mia domanda è: EF ha ragione per questo? Ci sono insidie su EF di cui non sono a conoscenza?

architecture orm entity-framework

— Rachel
fonte

Dai

— un'occhiata

7

Di recente stavo valutando Entity Framework e il posto migliore che ho trovato per problemi e funzionalità mancanti era: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Gli articoli con più voti:

Supporto per enumerazioni. Questo è piuttosto grande, ma al momento ci sono alcune soluzioni alternative
Generazione SQL migliorata. La velocità è molto importante soprattutto per le applicazioni a livello aziendale, ma sembra che con EF4 sia migliorata molto
Supporto per più database. Requisiti per qualsiasi applicazione di grandi dimensioni.

Ci sono molti altri problemi nell'elenco Voce utente.

In una nota a margine, sono piuttosto entusiasta della prossima versione di EF 4.1 che includerà l'approccio Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidate-available.aspx

Questo potrebbe effettivamente spingermi a provare EF in un'applicazione di produzione.

— Mag20
fonte

Argomentazione contro: 1st & 2nd & 3rd: It's SLOW !!! C'è una curva di apprendimento (è necessario sapere come eseguire un join sinistro: sono necessarie 3 ore per scoprire come farlo in modo che un'altra persona sappia cosa si sta facendo ...), il paging in LINQ invece di SQL (ad es. Feches 10 milioni di righe, quindi ne prende 20 da un offset arbitrario, e poi ti chiedi perché sia così lento) ... Il Repo è Non-Tread sicuro, devi iniziarlo su una base di query e l'inizializzazione del repo è MOLTO LENTO (come 5 secondi) se si dispone di un database più grande (ciò significa 100-200 tabelle, non DAVVERO DAVVERO di grandi dimensioni).

— Quandary

2

@Quandary Sembra che tu stia eseguendo IQueryables (cioè chiamando .ToList()o .ToArray) prima che le tue espressioni LINQ siano completamente definite. Ecco perché estrae tutti i record e rallenta.

— Orad,

6

Fare il ramo per bug / funzionalità con EF può essere notevolmente doloroso al momento della fusione. Immagina che due rami A e B apportino modifiche al database (che probabilmente accadrà molto durante le prime fasi di un nuovo progetto).

Unisci tutti i file "normali" - file cs, ecc. E poi è il momento di unire Model.edmx. E all'improvviso non stai solo unendo le mappature logiche tra il modello a oggetti e il database, ma anche le posizioni delle tabelle nel diagramma delle entità.

La fusione di Model.edmx è così dolorosa che abbiamo adottato un modo abbastanza brutto che funziona:

Durante l'unione, basta selezionare tutte le unioni da un genitore. Che non importa; toast presto il file comunque:
Ripristina Model.edmx su entrambi i genitori.
Migrare il database nel nuovo stato unito.
Aprire Model.edmx e "Aggiorna modello dal database".
Rinomina tutte le proprietà di navigazione tostate durante l'unione.

— Frank Shearar
fonte

1

Questa critica non è valida per il codice EF First ma si applica a Model First e Database First.

— Alan Macdonald,

Creo personalmente tutte le mappature usando Fluent e prendo il pieno controllo della mappatura. Questi sono inseriti in un file .cs separato.

— Steven Ryssaert,

5

Ci sono un paio di altri vantaggi in EF che ti mancano:

È possibile disporre di tabelle di span Entity
È possibile dividere una tabella in molti tipi di entità
È possibile generare le Entità dal database (ovvero database come approccio master)
È possibile generare il database dalle Entità (ovvero il codice come approccio principale)
Le query LINQ vengono tradotte in query SQL, migliorandone le prestazioni.

I lati negativi (in particolare se si utilizza la convalida):

È necessario creare un attributo [MetadataClass] che punti a un'altra classe con le proprietà che si desidera convalidare con gli attributi di convalida appropriati. Tutte le proprietà sono objecttipi, quindi è lì solo per leggere i metadati. Ancora molto codice inattivo aggiuntivo.
L'uso di EntityFramework è un concetto diverso rispetto al modo in cui qualcosa come NHibernate (e anche la versione Java madre) è progettata per funzionare. EntityFramework funziona meglio in una modalità collegata in cui gli oggetti utilizzano sempre una connessione attiva . NHibernate e strumenti ORM simili funzionano meglio in modalità indipendente in cui la connessione viene utilizzata solo durante il caricamento / salvataggio dei dati.

Queste sono le due maggiori lamentele che ho. Ci sono una serie di vantaggi, ma potresti benissimo essere in grado di ottenere gli stessi benefici da NHibernate. Se EntityFramework è sul tavolo, chiedi anche al team di controllare NHibernate e fare una rapida sparatoria per i pro / contro del tuo progetto.

Il problema della classe dei metadati è un mal di testa, ma per fortuna ho solo così tante entità che hanno bisogno di tag di validazione.

La mancanza di una vera modalità distaccata per i tuoi oggetti limita ciò che puoi fare in un ambiente web. La modalità allegata è migliore per le applicazioni desktop, che ha dato origine a numerose innovazioni Microsoft. La modalità indipendente è possibile , ma molto dolorosa. In questo caso è meglio usare uno strumento alternativo.

— Berin Loritsch
fonte

Il tuo cosiddetto codice come approccio principale è ufficialmente chiamato prima codice

— Robert Koritnik,

1

@Berin, voglio chiarire cosa intendi per "modalità collegata". Non credo che Entity Framework abbia sempre una connessione al database aperta. Credo che EF funzioni in modo simile a NHibernate al riguardo. È questo che intendi o intendi qualcos'altro? Hai un link alla documentazione che spiega ulteriormente questo problema allegato?

— RationalGeek,

1

Per allegato, intendo che tutte le tue interazioni con gli oggetti devono avvenire all'interno del using(EFConnection conn = new EFConnection)costrutto. Se tenti di riporre quell'oggetto da qualche parte per conservarlo in modo da poter fare un rapido aggiornamento e salvarlo di nuovo in una seconda using(...)istruzione, dovrai ripensarci. Vedere msdn.microsoft.com/en-us/library/bb896271.aspx e msdn.microsoft.com/en-us/library/bb896248.aspx . L'uso di EF 3.5 (che dovevo usare nell'ultima versione) non è nemmeno così pulito.

— Berin Loritsch,

Okay capisco cosa intendi adesso. Volevo solo assicurarmi che la gente non lo interpretasse nel senso che c'era sempre una connessione al database . È necessario disporre di un contesto oggetto che mantenga lo stato delle entità "associate".

— RationalGeek,

2

Questo non è vero. EF ha una forte idea di entità distaccate. Un'entità distaccata deve essere ricollegata al suo contesto prima di poter eseguire operazioni relative al contesto (come aggiornarlo nel database). Anche le classi di metadati sono necessarie solo se EF genera le tue entità per te. I POCO, IMO, sono un modo molto migliore di usare l'EF. L'uso dei POCO rende molte cose molto più semplici, in particolare i test.

— Matt Greer,

2

Una cosa in cui Microsoft non è molto brava è la compatibilità con la ~~comparabilità~~ all'indietro , specialmente quando si tratta di nuove tecnologie

Nello specifico EF1 (.net 3.5) è molto diverso da EF4 (.net 4.0) - lo stesso potrebbe accadere per la versione successiva.

Aspetterei un po 'e vedo come matura la tecnologia.

Nel frattempo, considera l'utilizzo di nHibernate: non è equivalente, ma è maturo e sfrenato.

— Ophir Yoktan
fonte

1

Semplicemente ... il modello di dominio raramente è una replica del modello relazionale nel database. Quindi mappare alcuni tavoli in una classe e gettarli sul filo è semplicemente pigrizia. Le tabelle potrebbero essere mappate localmente in 1 oggetto anche se il database è composto da 3 tabelle diverse. Progetta il database in modo intelligente.
2 ° questa roba EF non può generare determinate query e dovrai scriverle comunque.
3 ° Il modello di dominio non si associa direttamente ai servizi .. Si vorrà solo spingere il set di dati più minimale sul filo come DTO ... in particolare, se sta per comunicare con le app mobili.
5 La capacità di test ... Impossibile creare test abbastanza granulari che forniranno una regressione sufficiente contro le modifiche del codice ... tutto da risolvere facilmente
...

Potrei scrivere una diatriba di 10 pagine. Ma, se stai solo scrivendo un'app da buttare via per la società X .. a chi importa allora. Ma, se stai sviluppando un prodotto software ... dovrai essere molto più anale

— user104468
fonte

questo post è piuttosto difficile da leggere (wall of text). Ti dispiacerebbe modificarlo in una forma migliore?

— moscerino del

EF non genera oggetti di dominio. Quelli sono DAO. Dovrai utilizzare i dati dall'oggetto per creare il tuo oggetto dominio. Non dovresti comunque rispedire oggetti di dominio da un servizio, quindi crea il DTO più sottile dai tuoi oggetti di dominio prima di tornare. EF dovrebbe essere in grado di generare quasi tutto ciò che puoi esprimere in LINQ. Il database non fa parte di un test unitario, fa parte di un test funzionale. Detto questo, ci sono in memoria simulazioni disponibili per EF. In caso contrario, astrarre le query EF in un repository e quindi prenderlo in giro.

— Sinaestetico il

Sì, sono d'accordo. Piuttosto, mi riferisco ai modelli stabiliti da Martin Fowler e Carig Lairman. Alla fine della giornata, non posso usare CTE, PARTITION BY o CROSS APPLY. Inoltre, non posso usare un IDataReader che consente di mantenere basso l'overhead della memoria. Inoltre, quando

— eseguo

0

Dai un'occhiata a: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

I punti principali sono:

Mancanza di caricamento lento
Mancanza di perseveranza ignoranza
Il formato file utilizzato per il salvataggio del modello entità contiene entrambi gli elementi di visualizzazione e il modello entità stesso causa problemi di unione nell'ambiente del team.

Nota che il link sopra parla di EF1.

Anche questo link: http://ormeter.net/ mostra che EF non è il migliore rispetto ad altri ORM in termini di prestazioni e supporto LINQ.

— M.Sameer
fonte

Tieni presente che questo è stato pubblicato quando EF 1 era ancora di recente rilascio (o forse ancora in versione beta). Oggi la situazione è molto migliore con EF 4 e molte delle questioni sollevate in quel voto di sfiducia sono state risolte.

— RationalGeek,

L'ultimo punto conta ancora ed è molto significativo.

— M.Sameer

1

La prima versione EF era la 3.5. Non sono state rilasciate quattro versioni principali di EF.

— Matt Greer,

3

@Matt che è corretto. Ma la versione corrente si chiama EF 4 per allinearsi con il resto del versioning di .NET 4.

— RationalGeek,

1

Se è valido o meno, tuttavia, non dovrebbe influire sul riepilogo del collegamento. I voti mostreranno se è valido. :)

— Adam Lear