私はデータアクセス層を書いています。システム内の接続の管理について混乱しています。.net が接続プールを使用していることは知っています。しかし、すべての dml 操作またはすべての SQL クエリでデータベース接続を開いたり閉じたりしたくありません。どうすればこれを処理できますか? どこで、いつ (データ アクセス レイヤーを使用するグローバル asax またはデータ アクセス レイヤーで) 接続を管理する必要がありますか?
7 に答える
ステートメントのバッチを実行している場合を除き、クエリごとに SQL 接続を開いたり閉じたりする必要があります。
「遅く開き、早く閉じる」は、データベース接続を常に処理する方法です。
従来の方法 (独自のクエリを作成する) でそれを行う場合、MS は既に優れたデータ アクセス インターフェイスを作成しています。データ用のエンタープライズ ライブラリ(アプリケーション ブロック) には、適切に構成された優れた機能がすべて備わっています。
クエリの作成に煩わされたくない場合は、linq2Sqlまたはlinq2EF (推奨) を参照することをお勧めします。コーディングを大幅に簡素化します。
個別の論理操作ごとに接続を開閉したくないのはなぜですか? ほとんどの既存の DAL はそのように動作します。通常、接続をインテリジェントに管理するなど、ランタイムが自動的に行うことの裏をかこうとするのは得策ではありません。アプリにその複雑さを追加するために時間と労力を費やす前に、強力で実証可能な技術的ニーズが必要です。
トランザクションとして発生する必要がある操作についてはどうですか?
操作とロジック/検証を行うのはあなたの BL ですよね?
BLレイヤーがあるとしましょう
- お客様のアカウント情報を更新します。(DAL -> 顧客レコードの更新)
- 住所録を挿入します。(DAL -> アドレスを挿入)
- 3 番目のオブジェクトに対して顧客を検証します。(DAL -> クライアント & アドレス & 検証オブジェクトを取得)
結果: 顧客は無効です。したがって、トランザクションをロールバックする必要があります。
この問題を解決するにはどうすればよいでしょうか。
接続管理は、DAL によって管理されるべきではありません。
新しい接続を開く必要があるか、接続を閉じる必要があるかを担当/決定できる唯一の層は、DAL を使用するサービス層またはアプリケーション層です。そのレイヤーはコンテキストを認識している唯一のレイヤーであるため、このレイヤーは、同じ接続を使用する必要がある他の DB 通信があるため、接続を閉じるか、開いたままにするかを決定できる場所です。
実際、操作ごとに開閉する必要があります。Connection の使用をコストの高い操作と見なさないでください。サイトで接続を開くと、それらは接続プールに作成されます。接続を「閉じる」場合、接続プールは接続を解放しません。接続を手元に保持し、再利用できるようにします。したがって、新しい接続をもたらす最初の呼び出しには少し時間がかかりますが、その後の接続は非常に高速です。
更新: これは特に Web アプリケーションに当てはまります。グローバル オブジェクトで 1 回だけ接続を開いて、すべてのスレッドで再利用しようとしないでください。そうしないと、サイトが機能しなくなります。
古い質問に答える際のエチケットがよくわからず、別の回答にコメントする方法がわかりませんでした (私は SO にまったく慣れていないので、今日の最初のコーヒーを飲み終えていないので、たるみをカットしてください=])。
私は常に、すべてのクエリで接続を開閉するように DAL を作成し、ドライバーの接続プールに接続管理の作業を任せています。
ただし、共有 MS Access DB を使用するマルチユーザー デスクトップ アプリを使用しており (このアプリが作成された時点では、SQL Express は実際に使用可能な形式ではありませんでした)、破損を示すエラーが時々見られました。 この MS の記事では、アプリ全体で 1 つの接続のみを使用することを推奨しています。
「Microsoft Access データベースを繰り返し開いたり閉じたりすることはお勧めしません。アプリケーションの最初にデータベースを 1 回開き、アプリケーションの最後にデータベースを閉じます。」
私のアプリはマルチスレッドなので、衝突を避けるために「スレッドごとに1つの接続を開く」という推奨事項を修正する必要があると思います。共有 Access データベースを OLEDB や同様の破損の問題で使用した経験のある人はいますか?
.Net でいくつかのデータレイヤーを作成した後の私のアドバイス (以前は VB6 でさらにいくつか) は次のとおりです。
- 可能であれば、リーダーではなくデータセットを使用してください。
- 接続を確立および切断します (とにかく、1 つの接続で 1 つ以上のリーダーを開くことはできません)。
- バックエンドでパラメーター化された sps を使用して作業を行います。3.5 すべてのテーブルに一意の 1 フィールド主キーがあることを確認してください。
少しOT?...
- ORMクラスを生成するためにコード生成(あなたのものまたは購入済み)を使用します-しかし、それらはすべてではないことに注意してください(一度に1つのテーブルは便利です-しかし、1つのクエリが存在する醜い非効率的なコードを作成する可能性があります結合または狡猾なSPまたはビューを使用したバックエンドで、はるかにうまく機能します)。
- ConnectionオブジェクトのTransactionメソッドを読んでください-非常に便利です(ただし、トランザクションを必要とするいくつかの純粋なdbのもの(関係がある場合の削除など)は、バックエンドのトランザクションである可能性があります)。
私自身の最新の基本的な DAL (ORM なし) を作成するのに 30 分かかりましたが、コンパクトで非常に効率的です。MSエンタープライズのものは巨大です!!!
最後にもう 1 つ - 個人的には、xsds から生成された強く型付けされたデータセットは、ゲインに対する煩わしさ (および肥大化) が高いと考えています。それらを使用するために作成するコードもすべて肥大化します... または、それらを DataSet にダウンキャストして、効率的で反復のないコードのライブラリを実際に取得することになります。