Entity Framework Overkill per applicazioni Web?

Question

Diciamo che stiamo sviluppando un'applicazione Web E-Commerce per un'azienda di piccole e medie dimensioni. Supponiamo inoltre che il business possa ridimensionarsi nel tempo. In altre parole, la linea di prodotti crescerà tipicamente.

Fino ad ora ho sviluppato soluzioni di livello n utilizzando ADO.NET e stored procedure con l'aiuto della classe SqlHelper. Per le applicazioni più grandi ho usato Enterprise Library (2.0).

Mi piacerebbe passare a un approccio basato su ORM e sto iniziando a imparare LINQ oltre a passare da ASP.NET Web Form a ASP.NET MVC. Non voglio andare con LINQ-to-SQL. La domanda non è se è necessario un ORM, ma se l'ORM di Entity Framework è eccessivo per tale progetto. Non mi interessa una curva di apprendimento se è giustificata per il compito in mano.

Per quanto riguarda la "eccessivo", vorrei sapere se:

• EF è più veloce di una persona con le competenze giuste codifica query manualmente
• EF porta a codice non necessario gonfiare
• EF inutilmente scudi devs da dettagli a livello di codice delle loro domande
• LINQ to Entities è adatto per progetti di queste dimensioni

Infatti, se qualcuno pensa che un ORM sia eccessivo per tale progetto, mi piacerebbe sapere perché.

Answer 1

EF non è eccessivo per le app Web.

Non sono d'accordo con molto di quanto indicato nel vostro articolo di riferimento. Sono d'accordo che gli sviluppatori dovrebbero avere competenze decenti con SQL BUT ORMS fare un ottimo lavoro per ottenere un lavoro di sviluppo fatto più velocemente.

• Velocità di ORME - Stanno ottenendo meglio tutto il tempo & che consentono di chiamare SP del o modificare le query per ottenere la velocità massima in caso di necessità. Ci sono anche grandi profiler là fuori per il monitoraggio delle prestazioni ORM come EFProf.

• Rallenta la procedura di codifica - Davvero !!! Una volta imparato accelera lo su.

• Gli sviluppatori devono conoscere SQL: sono d'accordo. Tuttavia, ORMS in particolare con la sintassi LINQ spesso consente agli sviluppatori di scrivere più SQL complesso di quello che avrebbero sul proprio .

• Gli sviluppatori scrivono già query efficienti - REALMENTE !!!!! Basta chiedere al DBA i suoi pensieri! Mi capita di pensare che lo faccio, ma lo fanno anche tutti gli altri. Vedi il problema :-)

• Codice Bloat: non essere d'accordo, specialmente con quelli con LINQ .... Spesso rende il codice più leggibile e riduce spesso il numero di righe.

• Dimentica LINQ - Questa nave ha navigato . Rocce LINQ !!!! Vai con esso o essere lasciato alle spalle. Non è solo usato in ORMS. Può essere usato contro, array, oggetti, XML, file, twitter e l'elenco può continuare all'infinito .... Scopri LINQ.

L'articolo parla dell'ispirazione degli ultimi sviluppi della SM come provengono da Ruby on Rails. ROR ha un ORM basato su Active Record in esso .....

Gli ORMS sono buoni. Non devono essere usati ovunque e sempre ma sono buoni e dovrebbero essere considerati.

Answer 2

Assolutamente no. Vai avanti e usa EF.

Answer 3

EF ha una curva di apprendimento, ma qualsiasi cosa di nuovo fa. EF non è eccessivo, ma come per ogni sistema che viene scritto usa la tecnologia giusta per il progetto giusto.

Answer 4

Guardando l'articolo, la prima cosa che vorrei vedere e non essere d'accordo con questo:

Credo fermamente che la moderna web gli sviluppatori dovrebbero:

• database Amore.

• Scrivere query altamente efficienti.

• Riduci a icona il codice.

• Progettare interfacce utente ovvie.

• Operare rapidamente.

Non sono sicuro di quante persone visualizzino lo sviluppo Web, ma nella mia mente un deviatore del Web dovrebbe concentrarsi sulle funzionalità e sulle regole aziendali. Il database e il codice SQL puri non dovrebbero mai essere eseguiti da qualcuno del mio team che sarebbe più produttivo scrivere codice funzionale aziendale.

È qui che entra in gioco Entity Framework. È considerato uno strumento di sviluppo rapido delle applicazioni (come la maggior parte degli altri ORM). Questi strumenti sono creati appositamente per consentirti di concentrarti maggiormente su come soddisfare i requisiti degli utenti e meno su quale sia il modo corretto di scrivere una query.

Con ciò detto, vorrei anche dire che l'uso ingenuo dello strumento potrebbe essere pericoloso. Quando si utilizza Entity Framework è ancora necessario essere consapevoli delle implicazioni dell'utilizzo del grafico dell'oggetto che si sta richiedendo.

Non è eccessivo, lo strumento è molto semplice da usare e semplice da imparare. Direi che è più semplice "aggiustare" un Entity Framework piuttosto che fissare una query SQL e un insieme di transazioni ADO.

Su progetti più piccoli la mia raccomandazione di base è quasi sempre andare con qualche tipo di ORM. Sulle applicazioni aziendali devi essere un po 'più attento e dipende interamente dal budget :-).

Answer 5

Anche se questa è una risposta generale diffidare di qualsiasi opinione, che ha questi commenti in:

"utensile X puzza, scrivo in strumento di Y e posso farlo più velocemente che in strumento di X".

Ovviamente un oratore latino parla meglio in latino.

Answer 6

In realtà dipende dalla complessità del modello di dati piuttosto che dal tipo di applicazione.

Se si dispone di un modello di dati relativamente semplice, EF potrebbe essere eccessivo (se non lo si conosce ancora). Linq-to-SQL può essere una scelta migliore (meno curva di apprendimento, sebbene abbia anche limitazioni come nessuna mappatura molti-a-molti).

Se il modello di dati è più normalizzato, anziché solo basato sulla tabella, EF restituirà sicuramente a lungo termine, o Ibernare, o qualsiasi altro ORM più avanzato.

L'articolo a cui si fa riferimento sembra indicare che gli ORM in generale sono negativi, non solo EF. Di fronte alle sue argomentazioni, sembra in qualche misura in grado di respingerle. Sembra che stia cercando di giustificare un concetto generale (che i nuovi sviluppatori dovrebbero imparare la codifica di basso livello, in particolare SQL, prima di passare a strutture di alto livello) inventando punti discutibili.

Answer 7

Un ORM può essere molto utile, se usato correttamente e capire cosa sta facendo per voi. Dovresti sicuramente usarne uno, se hai già una certa conoscenza della progettazione e dell'interrogazione del database.

Il punto dell'articolo, in primo luogo, è che il concetto di non dover imparare nulla sulla progettazione del database e l'interrogazione in qualche modo rende la vita migliore è un errore. Preferisco livelli di astrazione molto sottili tra codice e database: mi sembra che mi concentri maggiormente sulla buona esperienza utente.

Personalmente ritengo che la stampa dietro EF incoraggia i nuovi programmatori a ignorare alcune nozioni di base necessarie. Ho lavorato con alcuni di loro e penso che abbiano fatto un cattivo servizio.

Certo, ci sono quelli che sono fortemente in disaccordo. Nessun problema!

Conosco gli sviluppatori che hanno iniziato ad amarlo, e ora no. Ma conosco anche sviluppatori che amano EF e ci giurano.

Ho utilizzato EF, LINQ su SQL e NHibernate e altri nel corso degli anni.

Il miglior consiglio: provalo. Vieni alla tua conclusione.

(Disclosure: Sono lo scrittore dell'articolo che hai citato).