Altre dichiarazioni sugli oggetti influenzano il programma?

Ecco alcune regole quasi sempre corrette:

Non dovresti mai riutilizzare una variabile per due scopi diversi.

Il caso in cui è necessario, è molto specifico, e quando lo vedi, lo saprai (il modello del peso mosca).

Dovresti mantenere i tuoi metodi molto brevi.

Il codice che hai mostrato può essere contenuto logicamente almeno in 3-5 metodi.

Non dovresti avere un codice duplicato. (DRY = Do not Repeat Yourself)

È probabile che linee di codice simili siano ripetute in più punti. Estrai questo in un unico metodo.

Per questo caso concreto, penso che tu abbia correttamente identificato le due dichiarazioni quasi identiche e le inizializzazioni della connessione, del comando e del lettore come un problema. Questa potrebbe essere una grossolana semplificazione, ma vivo ovunque ci sia duplicazione, c'è un problema di progettazione .

Pertanto sposterei la delcaricazione della connessione ecc. in cima al metodo, eseguo l'inizializzazione una sola volta e poi cambio solo il testo del comando nei due punti di utilizzo. Se la connessione viene utilizzata ripetutamente in tutta l'applicazione, potresti addirittura pensare di crearla una sola volta all'avvio dell'applicazione.

In generale, ci sono (almeno) due cose da bilanciare:

• Scopo variabile limitato: Da un lato, vuoi delcare le variabili il più vicino possibile a dove saranno utilizzate, così non dovrai mai chiedertici da dove provenga una variabile, come è stata inizializzata ecc. e non sarai tentato di riutilizzare una variabile per qualcos'altro.
• Consumo e rendimento delle risorse: l'apertura e la chiusura costanti di una connessione al database non sono probabilmente una buona idea, poiché è un'operazione (relativamente) lunga, comporta un sovraccarico sul server del database e potrebbe portare a una situazione dove la prima metà dell'operazione è completa, ma la seconda non riesce, perché la riconnessione al database non ha avuto esito positivo.

Poiché non hai dichiarato nessuna di queste variabili come statica, la tua scelta non avrà alcun impatto sull'applicazione. È semplicemente una questione di stile di codifica, organizzazione del codice e, infine, leggibilità.

Dato che la connessione non è soggetta a modifiche durante il lIfetime dell'applicazione, penso che abbia senso renderla statica in modo che tutte le istanze di classe possano condividerla.

D'altra parte, il comando può variare a seconda dei metodi e datareader sicuramente varierà per esecuzione, quindi ha senso dichiarare e istanziare quelli all'interno dei metodi del gestore di eventi.

In genere si desidera ottenere la connessione tramite un metodo da un'origine come un file di configurazione. Entro 1 transazione, potresti voler utilizzare 1 connessione. e si potrebbe anche voler assicurarsi che dopo un errore di connessione, un messaggio venga registrato o visualizzato e non venga eseguita alcuna ulteriore elaborazione. Gli errori di connessione sono frequenti durante lo sviluppo e la distribuzione e si consiglia di assicurarsi che vengano identificati separatamente dagli altri errori rari.

Ci sono molti modi per scrivere un codice che soddisfi i tuoi requisiti, ecco un modo:

    string sqlconnection=getCnString(); //getConnection obtains and formats cn string
    using (SqlConnection connection = new SqlConnection(sqlconnection)
    {
    try
    {
         connection.Open();
         //...do stuff with the open connection

         // for command 1
         try
         {
         //...create a command and do stuff with it.
         }
         catch ...
         {
         // send message or log message then exit via finally block
         }
         // for command 2
         try
         {
         //...create a command and do stuff with it.
         }
         catch ...
         {
         // send message or log message then exit via finally block
         }
       }
    catch (Exception as ex)
    {

          MessageBox.Show("Connection open Error:"+ex.Message);
          //don't code return here

    }
    finally
    {
      connection.Close();
      connection.Dispose();
    }
  } //automatic dispose could take care of the connection implicitly as well
  return;