Qual è il metodo migliore per passare i parametri a SQLCommand?

Question

Qual è il metodo migliore per passare i parametri a SQLCommand? Puoi fare:

cmd.Parameters.Add("@Name", SqlDbType.VarChar, 20).Value = "Bob";

o

cmd.Parameters.Add("@Name", SqlDbType.VarChar).Value = "Bob";

o

cmd.Parameters.Add("@Name").Value = "Bob";

Sembra che il primo potrebbe essere in qualche modo "migliore" dal punto di vista delle prestazioni o del controllo degli errori. Ma vorrei sapere più definitivamente.

Answer 1

Puoi anche usare AddWithValue () , ma fai attenzione alla possibilità di una conversione di tipo implicito errata.

cmd.Parameters.AddWithValue("@Name", "Bob");

Answer 2

Cosa sta succedendo lì?

Citi gli elenchi dei parametri per diversi sovraccarichi di Aggiungi . Questi sono metodi di convenienza che corrispondono direttamente ai sovraccarichi del costruttore per la classe SqlParameter . Fondamentalmente costruiscono l'oggetto parametro usando qualunque costruttore abbia la stessa firma del metodo di convenienza che hai chiamato, quindi chiamano SqlParameterCollection.Add (SqlParameter) in questo modo:

SqlParameter foo = new SqlParameter(parameterName, dbType, size);
this.Add(foo);

AddWithValue è simile ma offre ulteriore comodità, impostando anche il valore. Tuttavia, è stato effettivamente introdotto per risolvere un difetto del framework. Per citare MSDN,

  

Il sovraccarico di Aggiungi che richiede a   stringa e un oggetto è stato deprecato   a causa della possibile ambiguità con   Sovraccarico SqlParameterCollection.Add   che accetta un String e un SqlDbType   valore di enumerazione dove passare un   intero con la stringa potrebbe essere   interpretato come essere il   valore del parametro o il corrispondente   Valore SqlDbType . Usa AddWithValue   ogni volta che vuoi aggiungere un parametro   specificandone il nome e il valore.

I sovraccarichi del costruttore per la classe SqlParameter sono semplici vantaggi per l'impostazione delle proprietà dell'istanza. Accorciano il codice, con un impatto marginale sulle prestazioni: il costruttore può ignorare i metodi setter e operare direttamente sui membri privati. Se c'è una differenza, non sarà molto.

Cosa devo fare?

Nota quanto segue (da MSDN)

  

Per bidirezionale e output   parametri e valori di ritorno, tu   deve impostare il valore di Size . Questo è   non richiesto per i parametri di input e   se non impostato esplicitamente, il valore è   dedotto dalle dimensioni effettive di   parametro specificato quando a   viene eseguita un'istruzione con parametri.

Viene inserito il tipo predefinito. Tuttavia, se si consente di dedurre la dimensione in questo modo e si ricicla l'oggetto parametro in un ciclo (hai detto che eri interessato alle prestazioni), la dimensione verrà impostata dal primo valore e tutti i valori successivi più lunghi saranno ritagliato. Ovviamente questo è significativo solo per valori di lunghezza variabile come le stringhe.

Se si passa ripetutamente lo stesso parametro logico in un ciclo, si consiglia di creare un oggetto SqlParameter all'esterno del ciclo e di ridimensionarlo in modo appropriato. Il sovradimensionamento di un varchar è innocuo, quindi se è un PITA per ottenere il massimo esatto, basta impostarlo più grande di quanto ci si aspetti dalla colonna. Poiché stai riciclando l'oggetto anziché crearne uno nuovo per ogni iterazione, il consumo di memoria per tutta la durata del ciclo probabilmente diminuirà anche se ti ecciti un po 'con il sovradimensionamento.

A dire la verità, a meno che tu non elabori migliaia di chiamate, nulla di tutto ciò farà molta differenza. AddWithValue crea un nuovo oggetto, eludendo il problema di dimensionamento. È breve, dolce e facile da capire. Se fai un giro tra migliaia, usa il mio approccio. In caso contrario, utilizzare AddWithValue per mantenere il codice semplice e facile da mantenere.

---

Il 2008 era molto tempo fa

Negli anni da quando ho scritto questo, il mondo è cambiato. Esistono nuovi tipi di data e c'è anche un problema che non mi è passato per la mente fino a quando un recente problema con le date mi ha fatto riflettere sulle implicazioni dell'ampliamento.

L'ampliamento e il restringimento, per chi non ha familiarità con i termini, sono qualità delle conversioni dei tipi di dati. Se assegni un int a un doppio, non c'è perdita di precisione perché il doppio è "più largo". È sempre sicuro farlo, quindi la conversione è automatica. Questo è il motivo per cui puoi assegnare un int a un doppio ma andando nell'altro modo in cui devi fare un cast esplicito - double in int è una conversione restrittiva con potenziale perdita di precisione.

T

Answer 3

Direi sicuramente il numero 1. Tuttavia, tuttavia Microsoft lo fa nel blocco dell'applicazione di accesso ai dati nella libreria aziendale è il migliore, specialmente per il server SQL:

http://msdn.microsoft.com/en-us/library /dd203144.aspx

Answer 4

Prima usavo l'opzione 1:

  

cmd.Parameters.Add (" @ Name " ;, SqlDbType.VarChar, 20) .Value = " Bob " ;;

che ha funzionato bene, ma poi ho iniziato a usare .AddWithValue ed è semplice come si arriva. Non mi ha causato problemi dopo molte migliaia di usi. Intendiamoci, passo quasi sempre le variabili private delle mie classi, quindi non devo preoccuparmi tanto della conversione di tipo implicita.

Answer 5

Dipende dalla tua applicazione. In realtà mi piace 2, perché non mi piace cambiare il mio DAO se cambio la lunghezza di un parametro proc memorizzato. Sono solo io però. Non so se ci siano penalità di prestazione o altro.