Perché Dapper dot net non apre e chiude la connessione stessa?

Question

Dapper si aspetta implicitamente che una connessione sia aperta quando la utilizza. Perché non lo apre e lo chiude da solo? Non sarebbe semplicemente la gestione delle connessioni?

Chiedo perché un collega e io sto andando avanti e indietro sulla natura di ciò che accade dietro le quinte con il pool di connessioni, e se c'è qualche vantaggio nel mantenere una connessione aperta tra più comandi, o aprilo e chiudilo per ogni comando.

Answer 1

Dapper ora (e per un po 'di tempo) si occupa di questo internamente. Esso funziona solo ™

---

originale risposta (obsoleto):

Non sei sbagliato. Il motivo per cui non ho notato questo inconveniente è che per motivi legacy (in particolare: usavamo LINQ-to-SQL esclusivamente) la nostra connessione primaria-like-thing è una DataContext - quindi esporremo i metodi dapper come metodi di estensione su DataContext.

La cosa stupida è: ciò che questi metodi fanno è:

using(db.Connection.EnsureOpen()) { 
    db.Connection.{the dapper method} 
} 

Ecco EnsureOpen è un metodo sfacciato che:

• se la connessione è aperta, restituisce null
• in caso contrario, apre la connessione e restituisce un token IDisposable che chiude la connessione quando viene eseguito

Quindi: ci siamo sentiti ovviamente esattamente il tuo dolore, ma abbiamo implementato un livello più in alto.

Si prega di registrarlo come una richiesta di funzionalità. Noi abbiamo tutto il codice (anche se dovrò modificarlo leggermente per adattarlo al "lettore" per i dati non bufferizzati) - non c'è assolutamente alcun motivo per cui dapper non possa assumerne la proprietà.

Answer 2

Credo che Dapper non gestisca le connessioni in quanto è al di fuori delle sue responsabilità come mappatore ORM. Dapper non sa se riutilizzerai la stessa connessione in seguito - è per questo che accetta una connessione come uno dei parametri. Lo stesso vale per le transazioni: è l'applicazione che dovrebbe gestirlo, non il mappatore ORM.

È semplice scrivere i propri metodi di estensione che gestiscono la connessione.

Answer 3

Devo aggiungere una risposta contraria qui, o almeno suggerire che Dapper può gestire le connessioni in modo diverso, se non altro in determinate circostanze. Ho appena riflettuto su Dapper.SqlMapper e ci sono dei controlli nel metodo ExecuteCommand (chiamato out by Execute (sulle API pubbliche)) per verificare se una connessione è chiusa e poi la apre, se non lo è.

Mi sono imbattuto in questo come una revisione del codice da parte del mio collega ha sottolineato che non stavo chiamando esplicitamente un connection.open prima di chiamare via dapper al DB. Questo non è stato rilevato perché i miei test di integrazione erano tutti verdi, tutto era hunky-dory in fase di esecuzione. Quindi ci siamo tuffati nel codice di Dapper. Si potrebbe argomentare che è meglio chiamare open per esplicito, ma al contrario qualcuno potrebbe obiettare che meno codice è, meglio è.