Quali sono le migliori pratiche sulla gestione delle connessioni di database in .NET?

Question

Per quanto riguarda le best practice per la gestione delle connessioni di database in un'applicazione .NET, so che, in generale, è scorretto passare attorno a un oggetto di connessione.

Tuttavia, ho alcune curiosità specifici: (. Il bambino è privato)

---

1. Ho due istanze di affari oggetti, di classi diverse, in una relazione padre-figlio Quale delle seguenti è la migliore?

• Mantenere una connessione statica privata aperta e condivisa, utilizzato da entrambi gli oggetti, e ha lasciato aperta fino è disposto il genitore.

• Tenere aperte due connessioni statiche private, una per ciascun oggetto, non chiusa finché l'oggetto non viene eliminato.

• Non mantenere collegamenti statici; aprire e successivamente chiudere una nuova connessione per ogni metodo che lo richiede. Tuttavia, la maggior parte dei miei metodi esegue solo 1-3 query, quindi questo sembra inefficiente ...?

---

2. La seconda domanda è essenzialmente la stessa, ma per un singolo modulo. Cosa c'è di meglio qui?

• Mantenere una connessione statica privato aperto e condiviso per la vita del modulo.

• Non mantenere una connessione statica; aprire e successivamente chiudere una connessione per ogni metodo nella forma che richiede (di nuovo, a soli 1-3 query al metodo.)

Answer 1

(Era un commento) ...

La teoria è che non dovrebbe essere l'accesso al database e la logica di business - che dovrebbe essere in una classe di accesso ai dati separato. (Ad esempio, in futuro è necessario archiviarli offline in XML o utilizzare Oracle anziché SQL Server ... non si desidera riscrivere la logica aziendale!)

I propri oggetti aziendali non devono avere connessioni al database ad essi associate. La connessione deve essere aperta in alcuni metodi di tipo factory DAL, l'oggetto recuperato/creato, quindi la connessione chiusa e l'oggetto restituito.

Gli oggetti business stessi devono contenere campi e metodi di business logic, che possono richiamare il Data Access Layer, che dovrebbe creare una nuova connessione al database per ciascun metodo DAL.

Le tue paure di inefficienza possono essere messe a riposo usando Connection Pooling, il che significa che se apri e chiudi una connessione centinaia di volte, è probabile che utilizzeranno tutti la stessa. Ma non dovresti tenere a bada le connessioni al database, specialmente non come membri di una classe.

Spero che questo aiuti!

Answer 2

mia comprensione è che le connessioni devono rimanere aperto solo per il tempo necessario. La maggior parte del tempo che ho visto le connessioni in Uso di dichiarazioni, simile a

using (DBConnection db = new DBConnection(connectString)) 
{ 
    //do stuff 
} 

Answer 3

In risposta ad entrambe le domande, se si utilizza qualcosa che ha il pool di connessioni, come ADO.NET, si dovrebbe codificare le vostre domande a mantenere la connessione si apre come il più breve possibile. Cioè open and subsequently close a new connection for every method that requires it.. Quando si chiude la connessione, questo verrà restituito al pool di connessioni e riutilizzato in una query successiva e pertanto non si incorre in una penalità legata alle prestazioni aprendo e chiudendo un gruppo di connessioni. Il vantaggio è che non rischierai di perdere le connessioni che ti sei dimenticato di chiudere e, a lungo termine, avrai meno connessioni simultanee aperte rispetto a se manterrai le connessioni aperte per lunghi periodi di tempo. Non importa se l'applicazione è un modulo di Windows invece di un modulo Web: mantenere le connessioni aperte il più breve possibile.

Answer 4

Questo collegamento può essere utile: Best Practices for Using ADO.NET

Ecco un estratto interessante.

Per ottenere prestazioni ottimali, mantenere le connessioni al database aperta solo quando richiesto. Inoltre, riduci il numero di volte che apri e chiudi una connessione per più operazioni.

Ho sempre seguito la pratica di aprire le connessioni in un blocco using, in modo che il metodo Dispose (e quindi il metodo Close) venga sempre chiamato senza dovermi preoccupare. Usando questo approccio non ho mai riscontrato una situazione in cui le prestazioni scadenti fossero collegate a connessioni concorrenti eccessive oa operazioni di configurazione o di smantellamento eccessive.