Dapperは、接続を使用するときに接続が開いていることを暗黙的に期待します。なぜそれ自体を開閉しないのですか?これは単に接続管理ではないでしょうか。
同僚と私は、接続プールの舞台裏で何が起こっているのか、そして複数のコマンド間で接続を開いたままにすること、または接続を開いたり閉じたりすることに利点があるかどうかについて、行き来しているので、私は尋ねますコマンドごとに。
Dapperは、接続を使用するときに接続が開いていることを暗黙的に期待します。なぜそれ自体を開閉しないのですか?これは単に接続管理ではないでしょうか。
同僚と私は、接続プールの舞台裏で何が起こっているのか、そして複数のコマンド間で接続を開いたままにすること、または接続を開いたり閉じたりすることに利点があるかどうかについて、行き来しているので、私は尋ねますコマンドごとに。
Dapperは現在(そしてかなり長い間)これを社内で扱っています。それだけで動作します™</p>
元の(時代遅れの)答え:
あなたは間違っていません。この不便さに気づかなかった理由は、レガシーの理由(具体的には、LINQ-to-SQLを排他的に使用していた)のために、プライマリ接続のようなものがDataContext
-であるため、dapperメソッドを拡張メソッドとして再公開しますDataContext
。
ばかげたことは次のとおりです。これらのメソッドが行うことは次のとおりです。
using(db.Connection.EnsureOpen()) {
db.Connection.{the dapper method}
}
ここで、EnsureOpenは、次のような生意気なメソッドです。
だから:私たちは明らかにあなたの痛みを正確に感じましたが、それをさらに上の層に実装しました。
これを機能リクエストとしてログに記録してください。すべてのコードがあります(ただし、バッファリングされていないデータの「リーダー」に合うように少し調整する必要があります)。dapperがこれの所有権を取得できない理由はまったくありません。
ここに反対の答えを追加する必要があります。または、少なくとも、特定の状況でのみ、Dapperが接続を異なる方法で処理する可能性があることを提案します。Dapper.SqlMapperについて熟考しましたが、ExecuteCommandメソッド((パブリックAPIで)Executeによって呼び出される)で、接続が閉じられているかどうかを確認し、閉じられていない場合は開きます。
同僚によるコードレビューで、dapperを介してDBに呼び出す前に、connection.openを明示的に呼び出していなかったことが強調されたため、これに遭遇しました。私の統合テストはすべてグリーンであり、実行時にすべてが厄介だったため、これは取り上げられませんでした。そこで、Dapperコードに飛び込みました。明確にするためにオープンと呼ぶ方が良いと主張することもできますが、逆に、コードが少ないほど良いと主張する人もいます。
Dapperは、ORMマッパーとしての責任の範囲外であるため、接続を管理しないと思います。Dapperは、後で同じ接続を再利用するかどうかを知りません。そのため、Dapperは接続をパラメーターの1つとして受け入れます。同じことがトランザクションにも当てはまります。ORMマッパーではなく、トランザクションを管理する必要があるのはアプリケーションです。
接続を管理する独自の拡張メソッドを作成するのは簡単です。