Quando NON usare Entity Framework

.net architecture c# entity-framework

Domanda

Ho giocato con l'EF per vedere cosa può gestire. Anche molti articoli e post spiegano i vari scenari in cui l'EF può essere usato, tuttavia se manca il lato "con" in qualche modo. Ora la mia domanda è, in che tipo di scenari dovrei stare lontano da Entity Framework ?

Se hai esperienza in questo campo, dimmi quali scenari non si adattano bene all'EF. Parlami di alcuni aspetti negativi che hai sperimentato dove avresti voluto che avresti scelto una tecnologia diversa.

Risposta accettata

Sono anche solo sul palcoscenico del "suonare intorno" e, anche se ero preoccupato per la mancanza di agnosticismo persistente incorporato, ero sicuro che ci sarebbe stato un "work-around".

In realtà, nemmeno un work-around in un'architettura n-tier.

WCF + EF

Se ho letto correttamente l' articolo , quindi non vedo alcun problema serializzare le entità attraverso il filo (usando WCF) e anche l'ignoranza della persistenza non è un problema.

Questo perché userei PI principalmente per i test unitari.

È possibile testare l'unità! (credo)

In questo sistema, potremmo semplicemente usare un servizio di simulazione (avvolgendo la chiamata al servizio in un'altra classe basata sull'interfaccia che potrebbe essere prodotta da una fabbrica, per esempio). Questo testerebbe il nostro codice presentatore (non è necessario testare l'EF / DAL - questo è il lavoro di Microsoft!) Naturalmente, i test di integrazione sarebbero ancora necessari per raggiungere la piena sicurezza.

Se si volesse scrivere in un database separato, questo sarebbe fatto nel livello DAL, facilmente raggiungibile tramite il file di configurazione.

Il mio Tuppence vale la pena

La mia opinione - prendi la tua opinione sull'EF e non lasciarti scoraggiare da tutto il destino e l'oscurità riguardo a ciò che sta facendo il giro. Immagino che sarà in giro per un po 'e la MS risolverà i difetti nel prossimo anno o giù di lì. PI sta sicuramente arrivando secondo Dan Simmons.

EDIT : Ho appena realizzato che ho saltato la pistola e come un buon politico in realtà non ha risposto alla domanda che è stata posta. Ops. Ma lascerò questo nel caso in cui qualcun altro lo trovi utile.


Risposta popolare

The Vote of No Confidence elenca numerosi passaggi falsi e / o mancanti di funzionalità agli occhi di coloro che credono di sapere quali funzionalità e le loro implementazioni sono appropriate per i framework ORM / Datamapper.

Se nessuno di questi problemi è un grosso problema per te, allora non vedo perché non dovresti usarlo. Devo ancora sentire che si tratta di un caos buggy che esplode a destra ea sinistra. Tutte le ammonizioni contro di essa sono filosofiche. Sono d'accordo con il voto di sfiducia, ma questo non significa che dovresti. Se ti capita di apprezzare il modo in cui EF lavora, allora prendi il comando. Allo stesso tempo ti consiglierei di leggere almeno il voto di sfiducia e cercare di ottenere una comprensione rudimentale di ciascuno dei problemi al fine di prendere una decisione informata.

Al di fuori di questo problema e al centro della tua domanda, devi tenere d'occhio la Sql che viene generata in modo da poter apportare modifiche prima che un problema di prestazioni entri in produzione. Anche se stai usando procs nel back-end, cercherò comunque scenari in cui potresti colpire il database troppe volte e quindi rielaborare i tuoi mapping o gli scenari di recupero di conseguenza.



Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché