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

30

L'applicazione che sto attualmente costruendo ha utilizzato procedure memorizzate e modelli di classe realizzati a mano per rappresentare oggetti di database. Alcune persone hanno suggerito l'uso di Entity Framework e sto pensando di passare a questo poiché non sono così lontano nel progetto. Il mio problema è che sento che le persone che discutono di EF mi stanno solo dicendo il lato positivo delle cose, non il lato negativo:)

Le mie preoccupazioni principali sono:

  • Vogliamo la validazione lato client usando DataAnnotations, e sembra che devo comunque creare i modelli lato client quindi non sono sicuro che EF risparmierà molto tempo di codifica
  • Vorremmo mantenere le classi più piccole possibile quando si passa attraverso la rete, e ho letto che usare 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 Users, StatusCodes, Types, etc e più istanze dei nostri database principali per diverse istanze dell'applicazione. Le query SELECT possono ed eseguiranno query su tutte le istanze dei database, tuttavia gli utenti possono modificare solo gli oggetti presenti nel database su cui stanno lavorando. Possono cambiare i database senza ricaricare l'applicazione.
  • Le modalità oggetto sono molto complesse e ci sono spesso alcuni join coinvolti

Gli argomenti per EF sono:

  • Concorrenza. Non avrei bisogno di codificare i controlli per vedere se il record è stato aggiornato prima di ogni salvataggio
  • Generazione del codice. EF può generare modelli di classi parziali e POCO per me, tuttavia non sono sicuro che questo mi risparmierebbe molto tempo poiché penso che avremmo ancora bisogno di creare i modelli lato client per la convalida e alcuni metodi di analisi personalizzati.
  • Velocità di sviluppo poiché non avremmo bisogno di creare le stored procedure CRUD per ogni oggetto di database

La nostra architettura attuale consiste in un servizio WPF che gestisce le chiamate al database tramite stored procedure parametrizzate, oggetti POCO che vanno dal / al servizio WCF e il client WPF e il client desktop WPF stesso che trasforma POCO in classe Modelli per lo scopo di convalida e DataBinding.

Quindi la mia domanda è, EF è giusto per questo? Ci sono delle insidie riguardo EF di cui non sono a conoscenza?

    
posta Rachel 15.03.2011 - 15:04
fonte

6 risposte

7

Di recente stavo valutando Entity Framework e il posto migliore che ho trovato per problemi e funzionalità mancanti era: link

Gli articoli con più voti:

  1. Supporto per le enumerazioni. Questo è abbastanza grande, ma attualmente esistono alcuni accorgimenti
  2. Miglioramento della generazione SQL. La velocità è molto importante soprattutto per le applicazioni di livello enterprise, ma sembra che con EF4 sia migliorato molto
  3. Supporto per più database. Requisito per qualsiasi applicazione di grandi dimensioni.

Ci sono molti altri problemi nell'elenco delle voci dell'utente.

In una nota a margine, sono abbastanza entusiasta dell'imminente rilascio di EF 4.1 che includerà l'approccio Code-First ... link

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

    
risposta data 17.03.2011 - 13:37
fonte
5

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

  • Puoi avere una tabella di estensione Entity
  • Puoi dividere una tabella in molti tipi di entità
  • È possibile generare le entità dal database (ovvero database come approccio principale)
  • È possibile generare il database dalle Entità (ad esempio il codice come approccio principale)
  • Le query LINQ vengono tradotte in query SQL, migliorando le loro prestazioni.

Gli svantaggi (in particolare se stai usando la validazione):

  • Devi creare un attributo [MetadataClass] che punta a un'altra classe che ha le proprietà che vuoi convalidare con gli attributi di convalida appropriati. Tutte le proprietà sono tipi object , quindi è lì solo per leggere i metadati. Ancora un sacco di codice inattivo extra.
  • L'uso di EntityFramework è un concetto diverso rispetto al modo in cui qualcosa come NHibernate (e anche la versione di Java principale) è progettato per funzionare. EntityFramework fa meglio in una modalità collegata in cui gli oggetti utilizzano sempre una connessione live. NHibernate e strumenti ORM simili funzionano meglio nella modalità distaccata in cui la connessione viene utilizzata solo durante il caricamento / salvataggio dei dati.

Queste sono le due più grandi lamentele che ho. Ci sono molti vantaggi, ma tu potresti benissimo ottenere gli stessi benefici da NHibernate. Se EntityFramework è sul tavolo, invita anche la squadra a controllare NHibernate e fai una rapida uscita per i pro / contro per il 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à indipendente per gli oggetti limita ciò che puoi fare in un ambiente web. La modalità collegata è migliore per le applicazioni desktop, che è il luogo in cui sono nate numerose innovazioni Microsoft. La modalità distaccata è possibile , ma molto dolorosa. È meglio utilizzare uno strumento alternativo in questo caso.

    
risposta data 16.03.2011 - 19:49
fonte
5

Il fare branch-per-bug / feature 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 improvvisamente non stai solo fondendo i mapping logici tra il tuo modello di oggetti e il tuo database, ma anche le posizioni delle tabelle nel diagramma delle entità.

L'unione 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. Quale non importa; bruscamente presto il file:
  • Ripristina Model.edmx su entrambi i genitori.
  • Migrazione del database al nuovo stato unito.
  • Apri Model.edmx e "Aggiorna modello dal database".
  • Rinomina tutte le proprietà di navigazione tostate durante l'unione.
risposta data 17.03.2011 - 14:14
fonte
2

Una cosa che Microsoft non è molto brava è la compatibilità con le versioni precedenti , specialmente quando si tratta di nuove tecnologie

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

Aspetterei e vedere come matura la tecnologia.

Nel frattempo, prendi in considerazione l'utilizzo di nHibernate: non è equivalente, ma è maturo e viene utilizzato selvaggiamente.

    
risposta data 16.03.2011 - 20:13
fonte
0

Controlla questo: link

I punti principali sono:

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

Nota che il link sopra parla di EF1.

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

    
risposta data 16.03.2011 - 20:17
fonte
0
  • Semplicemente ... il modello di dominio è raramente una replica del relazionale modello nel tuo database. Quindi mappare alcune tabelle in una classe e gettarlo sul filo è semplicemente pigrizia. Tabelle potrebbe localmente mappare in 1 oggetto anche se il database è 3 differenti tabelle. Progettare il database in modo intelligente.
  • Secondo questo materiale EF non è possibile generare alcune query e avrai per scriverli comunque.
  • 3 ° Il modello di dominio non mappa direttamente sui servizi. Uno vorrà solo spingere il set di dati più minimale su filo come DTO .. soprattutto, se sta per essere in comunicazione con le app mobili.
  • 5Th capacità di test ... Impossibile creare test granulari sufficienti fornire una sufficiente regressione contro le modifiche al codice ... tutto per semplificare la ricerca pausa ...

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

    
risposta data 09.10.2013 - 23:01
fonte

Leggi altre domande sui tag