使い終わったらすぐに接続を閉じる必要があることは誰もが知っています。
ドメイン オブジェクト モデルの設計に問題があったため、ページのライフ サイクル全体にわたって接続を開いたままにしておく必要がありました。基本的に、最初の呼び出しで接続を開く Just In Time プロパティがあり、Page.Unload (..) で、db 接続が開いていたかどうかを確認し、開いていた場合は閉じます。1秒しかかからないので、すぐに閉じるのと大差ないという意見がありました。
これでよろしいですか？それとも、使用するたびにすぐに閉じる必要がありますか?
前もって感謝します。
いいえ、OKではありません。
アプリケーションを拡張または拡張する必要がある場合は、この問題を修正する必要があります。その接続を開いたままにすると、スケーリングの能力が低下します。開いている接続は、サーバー上のメモリ、クライアント上のメモリ、開いたロックの保持などを使用することに注意してください。
Page.Unload イベントに到達する前にページがクラッシュした場合はどうなりますか? 接続が開かれます。私にとっては、できるだけ早く接続を常に閉じることをお勧めします。
現在、すべての適切なASP.NETアプリは接続プールを使用しており、プールは基本的に開いている接続の集まりです。あなたの場合、それはあなたが保持している接続が「占有」されており、他のリクエストを処理するために使用できないことを意味します。
私が見る限り、ページが作業/レンダリングを行うのに必要な時間によっては、スケーラビリティの問題になるでしょう。あなたが言うように、100人のユーザーしか期待しない場合は、おそらく問題ではありません。もちろん、100 req/secでない限り。
技術的な観点からは問題ありません。私が覚えている限り、ほとんどのクライアントサーバーアプリケーション（Webおよび非Web）は、そのように機能するために使用される従来のASPコードを含みます。たとえば、ページ全体に対して1つの接続を宣言し、それを操作します。
理想的ではありませんが、アプリケーションを書き直すつもりはありません。ページがさまざまな方法で大量の時間のかかる作業を行っていない限り、ページのライフサイクル全体が迅速に実行されるはずです。実際には、接続オブジェクトが他の場合よりも数ミリ秒長く開いていることを意味するだけかもしれません。シナリオによっては重要かもしれませんが、あなたの場合はそうではないようです。
はい、大丈夫です。
できるだけ早く接続を閉じることは、孤立した開いている接続を防ぐためのベスト プラクティスですが、接続が閉じられていることが確実な場合は、何も問題はありません。
ページ中に複数のクエリを実行している場合は、ページの存続期間中、接続を開いたままにしておく必要があります。一般的に、実際には多くのページにまたがる接続を再利用します。
ページがクラッシュしますか？これは、使用するものであり、最終的には
とは言うものの、DBのパフォーマンス（つまりスケーリング）*のために、接続をできるだけ短い期間開いたままにしておくのが最善です。
*私はキャリアの早い段階でメンターからこれを言われました、私は実際にこれを自分でテストしたことはないと言わなければなりませんが、理論的には正しいように聞こえます
ORM（ Open Session in View ）を使用するときは、接続を開いたままにしておくと便利です。これにより、最初の熱心なフェッチの後、必要に応じて他のデータを遅延ロードできます。これは、接続を拘束しないようにページの応答時間が妥当な場合にうまく機能します。
もちろん、それらを開いたままにしておくことはできますが、できません。finally ブロックで使用した後は閉じます。「毎回の使用後」からの公正なトレードオフは、使用ブロックごとに閉じることです。ストアドプロシージャを実行し、列を更新してから他の行を削除する傾向がある場合は、これら3つの周りで開閉できますすべての操作が try/catch/finally でラップされていると仮定します。
より多くの情報に基づいた生産的なフィードバックを伴うより良い質問は、おそらくあなたがしていること (コード) の一部を提供し、あなたがこの選択をした理由を拡張することだと思います. 接続をそれほど長く開いたままにしておく必要のない、より良い解決策がある可能性が高いですが、少なくとも実用的な理由から、改良する価値があるかどうかについてフィードバックを得ることができます.
将来的には、コード ビハインドでのデータ アクセスから離れたいと思うことは間違いありません。