2011-01-06 9 views
12

Quando interrogare il database con la stessa query, ma diversi parametri, è meglio:È meglio riutilizzare SqlCommand quando si esegue la stessa query SQL più volte?

  • lo fanno in un unico utilizzando,
  • o per creare due query separate?

Esempio di un singolo utilizzando:

using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection)) 
{ 
    // Insert the first product. 
    addProduct.Parameters.AddWithValue("@name", "Product 1"); 
    addProduct.Parameters.AddWithValue("@price", 41F); 
    int countAffectedRows = addProduct.ExecuteNonQuery(); 
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected."); 

    addProduct.Parameters.Clear(); 

    // Insert the second product. 
    addProduct.Parameters.AddWithValue("@name", "Product 2"); 
    addProduct.Parameters.AddWithValue("@price", 49.9); 
    countAffectedRows = addProduct.ExecuteNonQuery(); 
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected."); 
} 

esempio dello stesso codice utilizzando due query separate:

// Insert the first product. 
using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection)) 
{ 
    addProduct.Parameters.AddWithValue("@name", "Product 1"); 
    addProduct.Parameters.AddWithValue("@price", 41F); 
    int countAffectedRows = addProduct.ExecuteNonQuery(); 
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected."); 
} 

// Insert the second product. 
using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection)) 
{ 
    addProduct.Parameters.AddWithValue("@name", "Product 2"); 
    addProduct.Parameters.AddWithValue("@price", 49.9); 
    int countAffectedRows = addProduct.ExecuteNonQuery(); 
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected."); 
} 

A mio parere, il secondo deve essere preferito , perché:

  • rende più chiaro vedere dove viene disposto il comando SQL e quante volte viene eseguito,
  • è più facile da modificare se, in futuro, per qualche motivo, la query deve essere modificata in un caso, ma non nell'altro,
  • il primo rende facile dimenticare lo SqlCommand.Parameters.Clear().

D'altra parte, il primo esempio è più esplicito sul fatto che la query è la stessa in entrambi i casi e che solo i parametri cambiano.

+2

Hai ragione, la seconda soluzione è più pulita. Non si dovrebbe riutilizzare lo stesso SqlCommand a meno che non si abbia intenzione di eseguire un hyper-mega tuning delle prestazioni. – Davita

+2

Forse dovresti inserire il codice inserto in una funzione separata e chiamarlo due volte. –

risposta

15

C'è poco vantaggio nel riutilizzo dell'istanza del comando, a meno che non si abbia intenzione di chiamare Prepare.

Se si esegue il comando molte volte (decine o più), probabilmente si desidera creare il comando, prepararlo, eseguirlo in un ciclo e quindi eliminarlo. I guadagni in termini di prestazioni sono significativi se si esegue il comando più volte. (Dovresti aggiungere i parametri una sola volta, prima di prepararti, non eliminarli e aggiungerli di nuovo ogni volta come nel tuo primo esempio di codice. Dovresti modificare i valori dei parametri ogni volta, non creare nuovi parametri.)

Se eseguirai il comando solo una volta, le prestazioni non sono un problema e dovresti scegliere lo stile che preferisci. Creare il comando ogni volta ha il vantaggio che è facile estrapolarlo in un metodo in modo da non ripetersi.

0

Se per "migliore" si intende "più chiaro" o "più pulito", utilizzare oggetti SqlCommand separati. Ciò contribuirà anche al refactoring del codice lungo la strada.

Se con "migliore" si intende "più veloce", riutilizzando SqlCommand si eliminerà la possibilità che venga creata una nuova SqlConnection (rispetto a quando viene estratto dal pool di connessioni).

+1

Entrambe le chiamate del costruttore nel secondo esempio utilizzano una connessione già aperta. – sisve

Problemi correlati