ASP.netでWebアプリケーションに取り組んでいます。私のアプリケーションにはいくつかのページがあり、それらすべてがデータベースによって作成されたテーブルを表示する必要があります。現在、私が行っているのは、各ページで、データベース接続を開き、そのページに固有のクエリを実行して、db接続を閉じることです。したがって、これは、ユーザーがリンクをクリックして新しいページに移動するか、グリッドページなどのフォームコントロールをクリックするたびに発生します。
パフォーマンスの観点から、これは災害だったのだろうかと思いました。これを行うためのより良い方法はありますか？
ほとんどの場合、データベース接続は次のように処理する必要があります。できるだけ遅く開き、できるだけ早く閉じます。複数のクエリ/更新のために開いたり閉じたり...開いたままにしても何も節約できないとは思わないでください。接続プールは一般に、接続の管理に非常に適しているためです。
1 つのページを作成する際に、いくつかの接続を開いたり閉じたりしてもまったく問題ありません。ページビュー間で単一の接続を開いたままにしようとすると、非常に悪いことになります...どのような状況でもそうしないでください。
基本的に、接続プール (ほとんどすべてのプロバイダーでデフォルトで有効になっています) を使用すると、接続を「閉じる」と、実際には再利用のためにプールに解放されます。自分でそれを開いたままにしようとすると、貴重なつながりが縛られます。
それはまさにあなたが望む方法です。データベース接続は、必要な場合にのみ開き、使用後すぐに閉じる必要があります。
特にパフォーマンスが大きな問題である場合に注目したいのは、キャッシュです。ページ全体、ページの一部のみ、またはページに表示したいデータのみをキャッシュしたい場合があります。この方法で多くのデータベーストリップを節約できますが、キャッシュを更新するタイミング、さまざまなユーザーのキャッシュなど、他のことを考慮する必要があります。
MSDNから-ADO.Netのベストプラクティス
高性能アプリケーションは、データソースへの接続を最小限の時間使用し続けるだけでなく、接続プーリングなどのパフォーマンス向上テクノロジーを利用します。
接続を開いてクエリを実行し、後で閉じるという、まったく問題ありません。接続を長期間保持し、複数のユーザーがアプリケーションにアクセスしている場合、データベースに通常設定されている接続制限を使い果たす可能性があります。
DB 接続をバックエンド コードに結び付けることは、悪い習慣です。学習しているように、データ インタラクションを UI にリンクするのではなく、Web サービスを使用して UI とやり取りすることをお勧めします。
UI(Aspx Page)のように >> BLL (ビジネスロジック層) >> DAL (データアクセス層)
また、DAL で「using」キーワードを使用して接続を破棄し、DB とのやり取りの後にすべてを試してください