ASP.NET/ADO.NET: Gestire molte connessioni al database all'interno di un oggetto .NET?

Question

Abbiamo un oggetto .NET che fa molta lettura / scrittura con il database. Durante tutto il ciclo di vita di questo oggetto (o della pagina asp che lo utilizza), potrebbe colpire il database con una query / aggiornamento da 1 a 10 volte.

Invece di aprire e chiudere una connessione al database ogni volta che l'oggetto deve colpire il database, apre semplicemente una connessione al database durante l'istanza e quindi chiude la connessione durante l'evento di terminazione dell'oggetto. È una cattiva pratica?

Il presupposto era che, dal momento che l'oggetto colpisce il database ogni volta che viene istanziato (e di solito più volte), sarebbe meglio aprire una connessione all'inizio della vita dell'oggetto e quindi chiuderlo alla fine.

L'altra alternativa è aprire e chiudere la connessione al database prima e dopo ogni query / operazione.

Qual è la migliore pratica qui per massimizzare le prestazioni?

**** **** aggiornamento Grazie per i consigli ragazzi. Qualcuno può parlare di più del metodo di apertura / chiusura di una connessione all'interno degli eventi di istanza / terminazione di un oggetto e delle ripercussioni di farlo?

Answer 1

Apri chiudi la connessione secondo necessità. ADO.NET ha un pool di connessioni integrato che funziona. Non noterai alcun problema di prestazioni a meno che tu non lo stia facendo in un ciclo con migliaia di aperture / chiusure.

modifica Vedi Devo persistere una connessione sql nel mio livello di accesso ai dati? per ulteriori informazioni sulle insidie ??della persistenza della connessione.

Answer 2

Apri e chiudi ogni volta ... Apri immediatamente (il più vicino possibile) prima della riga di codice che esegue effettivamente l'operazione del database e chiudi il più presto possibile immediatamente dopo. Quando si esegue questa operazione in questo modo, ADO.net NON chiude effettivamente la connessione, la rilascia semplicemente nel pool di connessioni ADO.net, dove si trova e attende la richiesta successiva per una connessione con la stessa stringa di conenction. Non stai affrontando l'ovale testa di ricreare effettivamente la connessione ogni volta ...

L'unico problema è se si eseguono in modo asincrono così tanti tentativi di connessione da superare il numero massimo di connessioni nel pool .... e ci sono anche soluzioni a questo problema, usando la classe System.Threading.ThreadPool. ..

Answer 3

Per aggiungere all'affidabilità nell'argomento del pool di connessioni - mantenere la connessione aperta più a lungo del necessario può effettivamente ridurre le prestazioni complessive, poiché il pool di connessioni non può condividere tale connessione con altri componenti che richiedono un DB collegamento.

Quindi, sì, apri e chiudi la connessione secondo necessità. Tuttavia, sarebbe ancora più veloce se si potesse raggruppare le query in una singola chiamata exec.

Answer 4

Anche quando ado.net NON chiude effettivamente la connessione, quando lo fai: Conn.Close () esegue " sp_reset_connection " sul server, anche quando sp_reset_connection è una procedura di archiviazione leggera, genera un po 'di traffico di rete. Ad esempio, non consiglierei di chiudere e aprire la connessione all'interno di un loop.