Qual è il modo migliore per interrogare i dati da un MS SQL Server in C #?
So che non è una buona pratica avere una query SQL nel codice.
È il modo migliore per creare una stored procedure e chiamarla da C # con i parametri?
using (var conn = new SqlConnection(connStr))
using (var command = new SqlCommand("StoredProc", conn) { CommandType = CommandType.StoredProcedure }) {
conn.Open();
command.ExecuteNonQuery();
conn.Close();
}
L'uso delle stored procedure è a senso unico ed è stato ampiamente utilizzato da molti anni.
Un modo più moderno per interagire con i database di SQL Server da C # (o qualsiasi linguaggio .NET) è utilizzare Entity Framework. Il vantaggio di Entity Framework è che fornisce un livello più alto di astrazione.
Per citare da Microsoft ( link ):
Il Entity Framework di ADO.NET consente agli sviluppatori di creare applicazioni di accesso ai dati programmando su un modello concettuale di applicazione invece di programmare direttamente su uno schema di archiviazione relazionale. L'obiettivo è ridurre la quantità di codice e manutenzione richiesta per le applicazioni orientate ai dati. Le applicazioni Entity Framework offrono i seguenti vantaggi:
L'uso di un ORM rispetto a stored procedure comporta compromessi, in particolare in termini di sicurezza e dove risiede la logica.
L'approccio "classico" allo sviluppo con SQL Server consiste nel far sì che la logica dell'applicazione risieda nelle stored procedure e programmi solo dati i diritti di sicurezza per eseguire stored procedure, non aggiornare direttamente le tabelle. Il concetto qui è che le stored procedure sono il livello della logica aziendale per le applicazioni. Sebbene la teoria sia valida, ha avuto la tendenza a non essere apprezzata per vari motivi, sostituita dall'implementazione della logica di business in un linguaggio di programmazione come C # o VB. Le buone applicazioni sono ancora implementate con un approccio a più livelli, inclusa la separazione delle preoccupazioni ecc. Ma sono più propensi a seguire un modello come MVC.
Uno svantaggio della logica di implementazione nell'ORM piuttosto che il database è la facilità di eseguire il debug e testare le regole di integrità dei dati da parte dei responsabili del database (DA o DBA). Prendiamo il classico esempio di trasferimento di denaro dal conto corrente al conto di risparmio, è importante che ciò avvenga come un'unità di lavoro atomica, in altre parole inserita in una transazione. Se questo tipo di trasferimento è consentito solo attraverso una procedura memorizzata, è relativamente facile per il DA e i revisori di QA la procedura memorizzata.
Se d'altra parte questo viene fatto tramite un ORM come Entity Framework e nella produzione si scopre che in rare occasioni il denaro viene prelevato dal controllo ma non messo nel risparmio, il debugging può essere molto più complesso, in particolare se più programmi sono potenzialmente coinvolti. Probabilmente si tratta di un caso limite, che potrebbe comportare problemi hardware particolari che devono verificarsi in una particolare sequenza, ecc. Come si fa a testare questo?
In realtà l'asserzione di base è discutibile - ci sono dei compromessi in entrambi i casi tra avere SQL nel codice o avere il codice nel database (che è dove stai andando con le stored procedure).
Il risultato è che non esiste un singolo "migliore", non è qualcosa che puoi generalizzare perché, in qualsiasi modo tu stia andando, stai facendo un compromesso (ottieni vantaggi ma anche limiti).
Se esiste una corrispondenza uno a uno tra l'applicazione e il database, allora non ha molta importanza. Se, d'altro canto, si dispone di un grande database principale condiviso da un numero significativo di applicazioni, l'applicazione della coerenza all'interno del database tra tali applicazioni diventa molto più importante.
La cosa più importante è preoccuparsi dell'architettura e della stratificazione della tua applicazione - dato un livello appropriato di accesso ai dati se usare un ORM come Entity Framework o NHibernate o fare qualcosa di più diretto dovrebbe isolare la maggior parte della tua applicazione da questa decisione indipendentemente dal fatto costruisci query o usi stored procedure.
Avrò la libertà di lavorare su progetti relativamente piccoli con piccoli team (1-3 sviluppatori) - l'uso di stored procedure è, per me, un problema maggiore del suo valore, data la natura delle nostre applicazioni (e del mio skillset? ) l'implementazione di un nuovo codice è in genere molto più semplice dell'aggiornamento dello schema (anche se consente di avere un codice che rende l'aggiornamento dello schema relativamente semplice) e sono in grado di applicare le regole aziendali utilizzando il codice di accesso ai dati comune. Questo è chiaramente un classico esempio di "Your Mileage May Vary".
Finché hai parametrizzato i tuoi input ogni approccio è valido. Molte delle query non in codice sono venute dai vecchi tempi in cui molte delle librerie ti obbligavano ad aggiungere stringhe alle tue istruzioni e da lì venivano gli attacchi di SQL injection.
Le migliori pratiche sono davvero esagerate qui: ci sono molti buoni modi per farlo e quello che scegli in realtà dovrebbe dipendere da cosa è la tua app e cosa devi fare. Detto questo, ci sono solo due cose che puoi fare davvero male:
Come sottolinea @Bill, devi sempre parametrizzare le tue query. La costruzione di stringhe è un vettore facile per l'iniezione di SQL e tutti i tipi di bug difficili da rintracciare. Le persone molto più intelligenti hanno capito come liberare e sql in modo da non aver bisogno di capirlo da solo.
Chiudi le connessioni. Il modo migliore è avvolgere tutto in una dichiarazione usando, ma provare / prendere / finalmente è bello anche se questo fa galleggiare la tua barca. Ma assicurati sempre di utilizzare una connessione come una macchina a basso costo, guidala in modo rapido e veloce e sbarazzati rapidamente.
L'altra pratica che vorrei sostenere con veemenza è che dovresti assicurarti di concentrare il tuo codice di accesso ai dati nel minor numero di posti possibile. Non permettiamo alle app web front-end di mantenere un riferimento diretto a System.Data.SqlClient per aiutare a far rispettare questo avvertimento.
Leggi altre domande sui tag c# sql sql-server