Entity Framework VS LINQ to SQL VS ADO.NET con stored procedure? [chiuso]

Come giudicheresti ciascuno di essi in termini di:

1. Prestazione
2. Velocità di sviluppo
3. Codice pulito, intuitivo, gestibile
4. Flessibilità
5. Complessivamente

Mi piace il mio SQL e quindi sono sempre stato un fan sfegatato di ADO.NET e delle procedure memorizzate, ma recentemente ho avuto un gioco con Linq to SQL e sono rimasto sbalordito da quanto velocemente stavo scrivendo il mio livello DataAccess e ho deciso di spendere un po 'di tempo capendo davvero o Linq to SQL o EF ... o nessuno dei due?

Voglio solo verificare che non ci sia un grande difetto in nessuna di queste tecnologie che renderebbe inutile il mio tempo di ricerca. Ad esempio, le prestazioni sono terribili, è interessante per le app semplici ma può arrivare solo lontano.

Aggiornamento: puoi concentrarti su EF VS L2S VS SP piuttosto che su ORM VS SP. Sono principalmente interessato da EF VS L2S. Ma sono desideroso di averli confrontati anche con i process memorizzati poiché il semplice SQL è qualcosa di cui so molto.

Prima di tutto, se stai avviando un nuovo progetto, scegli Entity Framework ("EF"): ora genera SQL molto migliore (più simile a Linq a SQL) ed è più facile da mantenere e più potente di Linq a SQL (" L2S "). A partire dal rilascio di .NET 4.0, considero Linq to SQL una tecnologia obsoleta. La SM è stata molto aperta a non continuare ulteriormente lo sviluppo di L2S.

1) Prestazioni

È difficile rispondere a questa domanda. Per la maggior parte delle operazioni a entità singola ( CRUD ) troverete prestazioni quasi equivalenti con tutte e tre le tecnologie. Devi sapere come funzionano EF e Linq to SQL per usarli al meglio. Per operazioni ad alto volume come le query di polling, è possibile che EF / L2S "compili" la query dell'entità in modo che il framework non debba rigenerare costantemente l'SQL o che si possano verificare problemi di scalabilità. (vedi modifiche)

Per gli aggiornamenti collettivi in ​​cui si stanno aggiornando enormi quantità di dati, SQL grezzo o una procedura memorizzata funzioneranno sempre meglio di una soluzione ORM perché non è necessario eseguire il marshalling dei dati via cavo sull'ORM per eseguire gli aggiornamenti.

2) Velocità di sviluppo

Nella maggior parte degli scenari, EF soffia via i proc SQL / stored nudi quando si tratta di velocità di sviluppo. Il designer EF può aggiornare il modello dal database man mano che cambia (su richiesta), quindi non si verificano problemi di sincronizzazione tra il codice oggetto e il codice del database. L'unica volta che non prenderei in considerazione l'utilizzo di un ORM è quando si sta eseguendo un'applicazione di tipo report / dashboard in cui non si esegue alcun aggiornamento o quando si crea un'applicazione solo per eseguire operazioni di manutenzione dei dati non elaborati su un database.

3) Codice pulito / mantenibile

Giù le mani, EF batte SQL / sprocs. Poiché le relazioni sono modellate, i join nel codice sono relativamente rari. Le relazioni delle entità sono quasi evidenti al lettore per la maggior parte delle domande. Niente è peggio che dover passare da un debug di livello a livello o attraverso più SQL / livello intermedio per capire cosa sta realmente accadendo ai tuoi dati. EF porta il tuo modello di dati nel tuo codice in un modo molto potente.

4) Flessibilità

I processi memorizzati e SQL raw sono più "flessibili". Puoi sfruttare sprocs e SQL per generare query più rapide per il caso specifico dispari e puoi sfruttare la funzionalità DB nativa più facilmente di quanto tu possa fare con ORM.

5) Complessivamente

Non lasciarti sorprendere dalla falsa dicotomia della scelta di un ORM rispetto alle procedure memorizzate. Puoi usare entrambi nella stessa applicazione e probabilmente dovresti. Le grandi operazioni in blocco dovrebbero essere eseguite in stored procedure o SQL (che può essere effettivamente chiamato dall'EF) e l'EF dovrebbe essere utilizzato per le operazioni CRUD e la maggior parte delle esigenze del livello intermedio. Forse sceglieresti di usare SQL per scrivere i tuoi rapporti. Immagino che la morale della storia sia la stessa di sempre. Usa lo strumento giusto per il lavoro. Ma il fatto è che EF è molto buono al giorno d'oggi (a partire da .NET 4.0). Trascorri un po 'di tempo in tempo reale leggendolo e capendolo in profondità e puoi creare con facilità fantastiche app ad alte prestazioni.

EDIT : EF 5 semplifica un po 'questa parte con le query LINQ compilate automaticamente , ma per cose veramente voluminose, dovrai sicuramente testare e analizzare ciò che si adatta meglio a te nel mondo reale.

Procedura di archiviazione:

(+)

• Grande flessibilità
• Pieno controllo su SQL
• Le massime prestazioni disponibili

(-)

• Richiede conoscenza di SQL
• Le procedure memorizzate sono fuori dal controllo del codice sorgente
• Quantità sostanziale di "ripetersi" specificando gli stessi nomi di tabella e campo. L'elevata probabilità di interrompere l'applicazione dopo aver rinominato un'entità DB e mancare alcuni riferimenti ad essa da qualche parte.
• Sviluppo lento

ORM:

(+)

• Sviluppo rapido
• Codice di accesso ai dati ora sotto controllo del codice sorgente
• Sei isolato dalle modifiche nel DB. In tal caso, è necessario aggiornare il modello / i mapping in un'unica posizione.

(-)

• Le prestazioni potrebbero essere peggiori
• Controllo scarso o scarso su SQL prodotto dall'ORM (potrebbe essere inefficace o peggiore). Potrebbe essere necessario intervenire e sostituirlo con stored procedure personalizzate. Ciò renderà il tuo codice disordinato (alcuni LINQ nel codice, alcuni SQL nel codice e / o nel DB fuori dal controllo del codice sorgente).
• Come ogni astrazione può produrre sviluppatori "di alto livello" che non hanno idea di come funzioni

Il compromesso generale è tra avere una grande flessibilità e perdere molto tempo rispetto a essere limitato in ciò che puoi fare ma averlo fatto molto rapidamente.

Non esiste una risposta generale a questa domanda. È una questione di guerre sante. Dipende anche da un progetto a portata di mano e dalle tue esigenze. Scegli ciò che funziona meglio per te.

la tua domanda è fondamentalmente O / RM vs SQL scrittura a mano

Usi un ORM o un semplice SQL?

Dai un'occhiata ad alcune delle altre soluzioni O / RM disponibili, L2S non è l'unica (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

per rispondere alle domande specifiche:

1. Dipende dalla qualità della soluzione O / RM, L2S è abbastanza bravo a generare SQL
2. Questo è normalmente molto più veloce usando un O / RM una volta che si avvia il processo
3. Il codice è di solito molto più ordinato e più gestibile
4. Naturalmente Straight SQL ti garantirà una maggiore flessibilità, ma la maggior parte degli O / RM può fare tutto tranne le query più complicate
5. Nel complesso, suggerirei di andare con un O / RM, la perdita di flessibilità è trascurabile

LINQ-to-SQL è una straordinaria tecnologia che è molto semplice da usare e in generale genera query molto buone sul back-end. LINQ-EF è stato programmato per soppiantarlo, ma storicamente è stato estremamente goffo da usare e ha generato SQL di gran lunga inferiore. Non conosco la situazione attuale, ma Microsoft ha promesso di migrare tutta la bontà di L2S in L2EF, quindi forse ora è tutto meglio.

Personalmente, ho una forte antipatia per gli strumenti ORM (vedi la mia diatriba qui per i dettagli), e quindi non vedo alcun motivo per favorire L2EF, dal momento che L2S mi dà tutto ciò che mi aspetto di aver bisogno da un livello di accesso ai dati. In effetti, penso persino che le funzionalità L2S come i mapping artigianali e la modellazione dell'ereditarietà aggiungano complessità completamente inutili. Ma sono solo io. ;-)

C'è un approccio completamente nuovo che potresti voler considerare se ciò che stai cercando è la potenza e le prestazioni delle procedure memorizzate e il rapido sviluppo che forniscono strumenti come Entity Framework.

Ho preso SQL + per un test drive su un piccolo progetto ed è davvero qualcosa di speciale. Fondamentalmente aggiungi ciò che equivale a commenti alle tue routine SQL e questi commenti forniscono istruzioni a un generatore di codice, che quindi crea una libreria di classi orientata agli oggetti davvero piacevole basata sulla routine SQL effettiva. Una specie di framework di entità simile al contrario.

I parametri di input diventano parte di un oggetto di input, i parametri di output e i set di risultati diventano parte di un oggetto di output e un componente del servizio fornisce le chiamate al metodo.

Se si desidera utilizzare le stored procedure, ma si desidera comunque uno sviluppo rapido, è possibile dare un'occhiata a queste informazioni.