Pourquoi Dapper dot net n'ouvre-t-il pas la connexion elle-même?

.net connection-pooling dapper sqlconnection

Question

Dapper s'attend implicitement à ce qu'une connexion soit ouverte lorsqu'elle l'utilise. Pourquoi ne l'ouvre pas et ne le ferme pas lui-même? Ne serait-ce pas simplement une gestion de connexion?

Je demande parce qu'un collègue et moi avons fait des allers-retours sur la nature de ce qui se passe dans les coulisses avec le regroupement de connexions, et s'il y a un avantage à garder une connexion ouverte parmi plusieurs commandes ou à l'ouvrir et la fermer pour chaque commande.

Réponse acceptée

Dapper maintenant (et pour un certain temps) traite de cette question en interne. Ça marche


Original (obsolète) réponse:

Tu n'as pas tort La raison pour laquelle je n'avais pas remarqué cet inconvénient est que, pour des raisons héritées (en particulier: nous DataContext exclusivement LINQ-to-SQL), notre principal objet de connexion est un DataContext - nous ré-exposons donc les méthodes dapper en tant que méthodes d'extension sur DataContext .

La bêtise est la suivante: ce que font ces méthodes est:

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

Ici EnsureOpen est une méthode effrontée qui:

  • si la connexion est ouverte, renvoie null
  • sinon, il ouvre la connexion et retourne un jeton IDisposable qui ferme la connexion une fois terminé

Donc: nous étions évidemment exactement votre douleur, mais nous avons mis une couche plus haut.

Veuillez vous connecter en tant que demande de fonctionnalité. Nous avons tout le code (bien que je vais devoir le modifier légèrement pour que le lecteur puisse lire les données non mises en mémoire tampon) - il n'y a absolument aucune raison pour que Dapper ne puisse pas en prendre possession.


Réponse populaire

Je dois ajouter une réponse contraire, ou au moins suggérer que Dapper peut gérer les connexions différemment, ne serait-ce que dans certaines circonstances. Je viens de réfléchir à Dapper.SqlMapper et il existe des vérifications dans la méthode ExecuteCommand (appelée par Execute (sur l'API publique)) pour vérifier si une connexion est fermée puis l'ouvrir si ce n'est pas le cas.

Je trouve cela comme une revue de code par mon collègue a souligné que je n'appelais pas explicitement une connexion.open avant d'appeler via dapper à la base de données. Cela n'a pas été pris en compte car mes tests d'intégration étaient tous verts, tout était parfait au moment de l'exécution. Nous avons donc plongé dans le code Dapper. On pourrait argumenter qu'il vaut mieux appeler ouvert pour plus de clarté, mais inversement, certains affirment que moins le code est bon, mieux c'est.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi