Best practice per eseguire query sui dati da MS SQL Server in C #?

Qual è il modo migliore per interrogare i dati da un MS SQL Server in C #?

So che non è buona norma avere una query SQL nel codice.

È il modo migliore per creare una procedura memorizzata e chiamarla da C # con 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 di stored procedure è un modo ed è stato ampiamente utilizzato per molti anni.

Un modo più moderno di interagire con i database di SQL Server da C # (o qualsiasi linguaggio .NET) consiste nell'utilizzare Entity Framework. Il vantaggio di Entity Framework è che fornisce un livello più elevato di astrazione.

Per citare da Microsoft ( https://msdn.microsoft.com/en-us/data/jj590134 ):

ADO.NET Entity Framework consente agli sviluppatori di creare applicazioni di accesso ai dati programmando su un modello di applicazione concettuale 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:

• Le applicazioni possono funzionare in termini di un modello concettuale più incentrato sull'applicazione, inclusi tipi con ereditarietà, membri complessi e relazioni.
• Le applicazioni vengono liberate da dipendenze codificate su un determinato motore di dati o schema di archiviazione.
• Le mappature tra il modello concettuale e lo schema specifico di archiviazione possono cambiare senza cambiare il codice dell'applicazione.
• Gli sviluppatori possono lavorare con un modello a oggetti di applicazione coerente che può essere mappato a vari schemi di archiviazione, eventualmente implementati in diversi sistemi di gestione del database.
• Più modelli concettuali possono essere associati a un singolo schema di archiviazione.
• Il supporto per le query integrate nella lingua (LINQ) fornisce la convalida della sintassi in fase di compilazione per le query rispetto a un modello concettuale.

L'uso di un ORM vs Stored procedure comporta compromessi, in particolare in termini di sicurezza e in cui risiede la logica.

L'approccio "classico" allo sviluppo con SQL Server consiste nel far sì che la logica dell'applicazione risieda nelle procedure e nei programmi memorizzati solo ai diritti di sicurezza per eseguire le procedure memorizzate, non all'aggiornamento diretto delle tabelle. Il concetto qui è che le stored procedure sono il livello di logica aziendale per le applicazioni. Sebbene la teoria sia valida, tende a sfuggire al favore per vari motivi, sostituendosi con l'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 hanno maggiori probabilità di seguire uno schema come MVC.

Un aspetto negativo dell'implementazione della logica nell'ORM piuttosto che nel database è la facilità di debug e test delle 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 unità di lavoro atomica, in altre parole inserita in una transazione. Se questo tipo di trasferimento può essere eseguito solo attraverso una procedura memorizzata, è relativamente facile per il procuratore generale e gli auditor eseguire la procedura memorizzata.

Se d'altra parte ciò avviene 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 debug può essere molto più complesso, in particolare se sono potenzialmente coinvolti più programmi. Questo sarebbe molto probabilmente un caso limite, che potrebbe comportare particolari problemi hardware che devono verificarsi in una sequenza particolare, ecc. Come si fa a testarlo?

In realtà l'asserzione di base è discutibile - ci sono dei compromessi in entrambi i casi tra avere SQL nel codice o avere codice nel database (che è dove ti stai dirigendo con le procedure memorizzate).

Il risultato è che non esiste un unico "migliore", questo non è qualcosa che si può generalizzare perché in qualunque modo si sta facendo un compromesso (si ottengono benefici ma si introducono anche vincoli).

Se esiste una corrispondenza uno a uno tra l'applicazione e il database, non importa. Se, d'altra parte, si dispone di un ampio database core condiviso da un numero significativo di applicazioni che garantiscono 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 di accesso ai dati appropriato sia che usi un ORM come Entity Framework o NHibernate o che faccia qualcosa di più diretto, dovresti isolare la maggior parte della tua applicazione da questa decisione, indipendentemente dal fatto che tu crei query o utilizzare le procedure memorizzate.

Avrei liberamente teso a lavorare su progetti relativamente piccoli con piccoli team (1-3 sviluppatori) - l'utilizzo di procedure memorizzate è, per me, più problemi del suo valore perché, data la natura delle nostre applicazioni (e il mio skillset?), Implementando nuove il codice è generalmente molto più semplice dell'aggiornamento dello schema (anche consentendo di disporre di un codice che renda relativamente semplice l'aggiornamento dello schema) e sono in grado di applicare le regole di business utilizzando un codice di accesso ai dati comune. Questo è chiaramente un classico esempio di "Il tuo chilometraggio può variare".

Finché hai parametrizzato i tuoi input, ogni approccio è valido. Gran parte del non avere domande negli argomenti del codice proveniva dai brutti vecchi tempi in cui molte delle biblioteche ti costringevano ad aggiungere stringhe le tue dichiarazioni insieme ed è da lì che provenivano gli attacchi di iniezione sql.

Le migliori pratiche qui sono davvero esagerate - ci sono molti buoni modi per farlo e quello che scegli davvero dovrebbe dipendere da cosa è la tua app e cosa devi fare. Detto questo, ci sono solo due cose che puoi fare davvero di sbagliato:

• Come sottolinea @Bill, dovresti sempre parametrizzare le tue query. La creazione di stringhe è un vettore semplice per l'iniezione di SQL e tutti i tipi di bug difficili da rintracciare. Le persone molto più intelligenti hanno capito come tupelizzare e sfuggire a sql, quindi non è necessario capirlo da soli.

• Chiudi le tue connessioni. Il modo migliore è racchiudere tutto in un'istruzione using, ma provare / catturare / finalmente è anche bello se questo fa galleggiare la tua barca. Ma assicurati sempre di utilizzare una connessione come un'auto economica: guidala forte e veloce e sbarazzati di essa rapidamente.

L'altra pratica per la quale vorrei contestare con veemenza è che dovresti assicurarti di concentrare il codice di accesso ai dati nel minor numero di posti possibile. Non consentiamo alle app Web front-end di contenere un riferimento diretto a System.Data.SqlClient per aiutare a far rispettare questo avvertimento.