Qual è il “migliore” approccio / approccio di accesso ai dati per C # e .NET?

(EDIT: l’ho reso un wiki della comunità in quanto è più adatto a un formato collaborativo.)

Esistono molti modi per accedere a SQL Server e altri database da .NET. Tutti hanno i loro pro e contro e non sarà mai una semplice domanda di quale sia “il migliore” – la risposta sarà sempre “dipende”.

Tuttavia, sto cercando un confronto ad alto livello dei diversi approcci e quadri nel contesto dei diversi livelli di sistemi . Ad esempio, immagino che per un’applicazione Web 2.0 veloce e sporca la risposta sia molto diversa da un’applicazione CRUD aziendale di livello Enterprise.

Sono consapevole del fatto che ci sono numerose domande su Stack Overflow che si occupano di sottoinsiemi di questa domanda, ma penso che sarebbe utile provare a creare un confronto di riepilogo. Cercherò di aggiornare la domanda con correzioni e chiarimenti man mano che procediamo.

Finora, questa è la mia comprensione ad alto livello, ma sono sicuro che sia sbagliato … Mi sto concentrando principalmente sugli approcci Microsoft per mantenere questo objective.

ADO.NET Entity Framework

  • Database agnostico
  • Buono perché consente di scambiare i backend dentro e fuori
  • Cattivo perché può colpire le prestazioni e i fornitori di database non ne sono troppo contenti
  • Sembra essere il percorso preferito di MS per il futuro
  • Complicato per imparare (però, vedi 267357 )
  • Vi si accede tramite LINQ alle Entità in modo da fornire ORM, consentendo così l’astrazione nel codice

LINQ a SQL

  • Futuro incerto (vedi LINQ to SQL veramente morto? )
  • Facile da imparare (?)
  • Funziona solo con MS SQL Server
  • Vedi anche Pro e contro di LINQ

ADO.NET “standard”

  • Nessun ORM
  • Nessuna astrazione in modo da tornare a “rollare il tuo” e giocare con SQL generato dynamicmente
  • Accesso diretto, consente prestazioni potenzialmente migliori
  • Ciò si ricollega al vecchio dibattito sull’opportunità di concentrarsi su oggetti o dati relazionali, a cui ovviamente la risposta è “dipende da dove si trova la maggior parte del lavoro” e dal momento che si tratta di una domanda irrisolvibile speriamo di non devo entrare troppo in quello. IMHO, se la tua applicazione sta principalmente manipolando grandi quantità di dati, non ha senso estrapolarla troppo in oggetti nel codice front-end, stai meglio usando le stored procedure e SQL dinamico per fare tutto il lavoro ansible sul back-end. Considerando che, se si dispone principalmente di interazione dell’utente che causa l’interazione del database a livello di decine o centinaia di righe, ORM ha perfettamente senso. Quindi, suppongo che il mio argomento per il buon vecchio stile ADO.NET sia nel caso in cui manipoli e modificherai grandi set di dati, nel qual caso beneficerai dell’accesso diretto al back-end.
  • Un altro caso, ovviamente, è dove devi accedere a un database legacy che è già protetto da stored procedure.

Controlli origine dati ASP.NET

Sono qualcosa di completamente diverso o solo uno strato rispetto a ADO.NET standard? – Utilizzeresti davvero queste cose se tu avessi un DAL o se hai implementato LINQ o Entità?

NHibernate

  • Sembra essere un ORM molto potente e potente?
  • Open source

Alcuni altri link rilevanti; NHibernate o LINQ to SQL Entity Framework vs LINQ to SQL

Penso LINQ to SQL è buono per i progetti destinati a SQL Server.

ADO.NET Entity Framework è migliore se stiamo prendendo di mira diversi database. Attualmente penso che molti provider siano disponibili per ADO.NET Entity Framework, Provider per PostgreSQL, MySQL, esql, Oracle e molti altri (controlla http://blogs.msdn.com/adonet/default.aspx ).

Non voglio più usare ADO.NET standard perché è una perdita di tempo. Vado sempre per l’ORM.

Avendo lavorato su oltre 20 diversi progetti C # / ASP.NET, finisco sempre per utilizzare NHibernate . Spesso inizio con uno stack completamente diverso: ADO.NET, ActiveRecord, laminazione a mano. Ci sono numerosi motivi per cui NHibernate può funzionare in una vasta gamma di situazioni, ma la cosa che spicca di più è il risparmio di tempo, specialmente se collegato alla generazione del codice. È ansible modificare la datamodel e le entity framework vengono ricostruite, ma la maggior parte / tutti gli altri codici non devono essere modificati.

La SM ha una brutta abitudine di spingere le tecnologie in quest’area parallelamente all’open source esistente, per poi lasciarle cadere quando non decollano. Qualcuno ricorda ObjectSpaces?

Aggiunto per nuove tecnologie:

Con Microsoft Sql Server out per Linux in Beta adesso, penso che sia ok non essere agnostico nei database. Il .Net Core Path e MS-SQL route ti permettono di girare su server Linux come Ubuntu interamente senza dipendenze da Windows.

Pertanto, un stream molto buono è quello di non utilizzare un framework ORM completo o controlli di dati e sfruttare la potenza dei progetti SSDT Visual Studio (Sql Server Data Tools) e un Micro ORM.

In Visual Studio è ansible creare un progetto server Sql come progetto di Visual Studio legittimo. In questo modo è ansible creare l’intero database tramite designer di tabelle o modifica di query raw direttamente all’interno di Visual Studio.

In secondo luogo, si ottiene lo strumento Confronta schema di SSDT che è ansible utilizzare per confrontare il progetto di database con un database attivo in Microsoft Sql Server e aggiornarlo. È ansible sincronizzare il progetto Visual Studio con il server causando gli aggiornamenti nel progetto per uscire sul server. Oppure puoi sincronizzare il server con il tuo progetto e far sì che il tuo codice sorgente si aggiorni. Tramite questo percorso è ansible rilevare facilmente le modifiche apportate al DBA in manutenzione la scorsa notte e trasferire facilmente le nuove modifiche di sviluppo per una nuova funzione con un semplice strumento.

Utilizzando lo stesso strumento è ansible calcolare lo script di migrazione senza eseguirlo effettivamente, se è necessario trasferirlo a un reparto operativo e inviare un ordine di modifica, funziona per tale stream.

Ora per scrivere codice contro il tuo database MS-SQL, ti consiglio PetaPoco.

Perché PetaPoco funziona perfettamente in linea con la soluzione SSDT di cui sopra. PetaPoco viene fornito con modelli di testo T4 che è ansible utilizzare per generare tutte le classi di quadro dati e genera per te le classi del livello dati bulk.

Il problema è che devi scrivere query tu stesso, che non è una brutta cosa.

Quindi finisci con qualcosa del genere:

var people = dbContext.Fetch("SELECT * FROM People where Username Like '%@0%'", "bob"); 

PetaPoco gestisce automaticamente la parametrizzazione @ 0 per te, ha anche la pratica class Sql per la creazione di query.

Inoltre, PetaPoco è un ordine di grandezza più veloce di EF6 e 8+ volte più veloce di EF7.

Quindi, in totale, questa soluzione implica l’utilizzo di SSDT per la gestione di SCHEMA e PetaPoco per l’integrazione del codice al guadagno di elevata manutenibilità, personalizzazione e prestazioni molto buone.

L’unico inconveniente di questo approccio è che ti stai legando a Microsoft Sql Server. Tuttavia, Microsoft Sql Server è uno dei migliori RDBM disponibili.

Ha funzionalità DBMail, Jobs, oggetti CLR e così via. Inoltre l’integrazione tra Visual Studio e il server MS-SQL è fenomenale e non si ottiene nulla se si sceglie un RDBMS diverso.

Devo dire che non ho mai usato NHibernate per il tempo immenso che è necessario iniziare a utilizzare … il tempo sprecato nella configurazione XML .

Recentemente ho fatto un’applicazione web in MVC2 , dove ho scelto ADO Entities Framework e uso Linq tutto il tempo.

Devo dire che sono rimasto impressionato dalla velocità ! e il nostro sito aveva circa 35.000 visitatori unici al giorno, con una larghezza di banda di circa 60 Gb al giorno (ho ridotto radicalmente questo numero di 60 Gb ospitando tutti i file statici in Amazon S3 – il grande wrapper .NET che hanno, devo dire).

Andrò sempre così . È facile da avviare (basta aggiungere un nuovo elemento di dati, scegliere le tabelle e il gioco è fatto! Per ogni modifica nel database abbiamo solo bisogno di aggiornare il modello, fatto automaticamente in soli 2 clic) ed è divertente da usare: le regole di Linq!