ADO.NETの実践例の紹介

ADO.NET の利点を最大限に活用するには、ADO.NET プログラミング モデルを包括的かつ深く理解する必要があるだけでなく、経験とスキルをタイムリーに要約することも非常に重要です。 ADO には長年の実践経験があり、ADO.NET はこれに基づいて、より豊富で強力なツールを提供します。ただし、ADO.NET の設計目標は結局のところ、プラグ アンド プレイ ツールを提供することではなく、統合されることはありません。 all プログラミング作業はマウスクリックだけで完了できるほど簡略化されています。
ADO.NET には、データ アクセス モデルのさまざまな論理エンティティを表す多数のオブジェクトが含まれており、その中で接続とトランザクションの 2 つのオブジェクトが最も重要です。接続の機能は、バックエンド データベースと通信するためのチャネルを確立することです。接続オブジェクトの作成は、特定の .NET データ プロバイダーに基づいて行う必要があります。トランザクション オブジェクトは、既存の接続オブジェクト上に作成するか、BEGIN TRAN SQL ステートメントを明示的に実行することによって作成できます。理論は単純ですが、実際には、接続とトランザクションの周りには多くの不確実な要素があり、それらはアプリケーション全体の安定性と効率に重大な影響を与えます。

接続文字列を保存し、接続文字列に含まれる可能性のある機密情報(パスワードなど)を保護するにはどうすればよいですか?パフォーマンスやスケーラビリティに大きな影響を与えずに、セキュリティ (認証、認可など) を考慮した完全なデータ アクセス ポリシーを設計するにはどうすればよいでしょうか?トランザクションが必要な場合、トランザクションを効率的に実装および制御するにはどうすればよいでしょうか?自動トランザクションを使用しますか?それとも手動トランザクションを使用しますか? ADO.NET を使用する場合は、これらの問題を慎重に考慮する必要があります。

1. 接続文字列、接続プール

データベース接続は重要かつ限定的で高価なリソースであるため、接続オブジェクトを有効に活用することは、あらゆるアプリケーションにとって最も基本的な要件です。データベース接続を使用する際の重要なポイントは次のように要約できます:

接続文字列を保存するときは安全性に注意してください。
接続は遅く開かれ、接続は早く閉じられるべきです。
接続文字列はデータベースにアクセスするためのキーです。接続文字列には、アクセスするデータの記述に加えて、ユーザーがそのデータにアクセスできる理由を示す ID の証明も含まれます。ユーザー認証は、データベース操作を実行する際のデータ アクセス権を決定する際の最も重要な要素です。

1.1 接続文字列の保存

現時点では、ハードコーディングされた接続文字列はアプリケーション コードに直接コンパイルされるため、最高のパフォーマンスが得られます。ただし、ハードコーディングされた文字列はプログラムの柔軟性に影響を与えるため、接続文字列が変更されるとアプリケーションを再コンパイルする必要があります。

接続文字列を外部に保存すると、外部文字列にアクセスするための追加のオーバーヘッドが犠牲になりますが、柔軟性が向上します。しかし、ほとんどの場合、結果として生じるパフォーマンスのオーバーヘッドは無視できるものであり、本当に心配する必要があるのはセキュリティです。たとえば、攻撃者は接続文字列を変更したり盗んだりする可能性があります。接続文字列を外部環境に保存する一般的な方法は、構成ファイル、UDL ファイル、Windows レジストリです。

.NET Framework 構成ファイルはプレーン テキスト ファイルの形式でデプロイされ、簡単にアクセスできます。接続文字列にパスワードが含まれている場合、パスワードはクリア テキストで保存されるため、テキスト形式が最大の欠点となります。専用の暗号化/復号化エンジンの導入を検討できますが、この部分の作業は開発者自身が行う必要があります。

UDL ファイルは、OLE DB プロバイダーによって使用されるテキスト ファイルです。つまり、SQL Server ホスティング プロバイダーは UDL ファイルをサポートしません。 UDL ファイルにも以前の構成ファイルと同じセキュリティ問題があり、全体的にはあまり利点がありません。

最後に、Windows レジストリは自然に安全な保管場所として機能します。レジストリは、鍵情報を格納するシステム知識ベースであり、暗号化技術と組み合わせることで、より高いセキュリティを実現できます。レジストリを使用する主な欠点は、展開が面倒であること、レジストリ キーの作成 (場合によっては暗号化の実行) とレジストリからのデータの読み取りが必要なことです。 .NET Framework は、基盤となる Win32 API を呼び出すカプセル化されたクラスのセットを提供しますが、これらのクラスはいずれも暗号化機能を提供しません。 aspnet_setreg.exe ツールを使用すると、HKEY_LOCAL_MACHINE の下に登録キーを作成し、ユーザー名とパスワードを保存できます (例: aspnet_setreg.exe -k "SoftwareMyData" -u:userID -p:password)。このコマンドは、指定されたユーザー ID とパスワードを暗号化します。

1.2 接続プールの原則

接続プールを使用すると、バッファプールを通じて既存の接続オブジェクトを再利用できるため、接続オブジェクトが使用されるたびに新しいオブジェクトを作成する必要がなくなります。接続プールを使用した後は、少数の接続オブジェクトのみが多数のクライアントのニーズを満たすことができます。

各接続プールは、独立した接続文字列とそのトランザクション コンテキストに関連付けられます。新しい接続が開かれるたびに、データ プロバイダーは、指定された接続文字列と接続プールの文字列を照合しようとします。一致が失敗した場合、データ プロバイダーは新しい接続を作成し、それを接続プールに追加します。接続プールは作成後、プロセスが終了しない限り削除されません。この処理方法がパフォーマンスに影響すると考える人もいます。実際、非アクティブまたは空の接続プールを維持するのにそれほどコストはかかりません。

接続プールが作成された後、システムはいくつかの接続オブジェクトを作成し、接続オブジェクトの定格最小数に達するまでそれらを接続プールに追加します。今後、システムは、接続オブジェクトの最大数に達するまで、必要に応じて接続オブジェクトを作成および追加します。プログラムが接続オブジェクトを要求したときに使用可能な空き接続オブジェクトがなく、接続プール内のオブジェクトの数が上限に達した場合、要求はキューに入れられ、接続が解放されてバッファ プールに戻されます。 、すぐに取り出して使用します。

プログラムで接続文字列を構築することは避けてください。接続文字列が複数の入力データを結合して構築されている場合、インジェクション攻撃が悪用しやすくなります。ユーザーが入力したデータを使用する必要がある場合は、厳密な検証を実行する必要があります。

1.3 接続を閉じる

接続が閉じられると、接続オブジェクトは再利用のために接続プールに返されますが、この時点では実際のデータベース接続は解体されません。接続プーリングが無効になっている場合、実際のデータベース接続も閉じられます。ここで強調しなければならない点は、接続オブジェクトは使用後に明示的に閉じて接続プールに戻す必要があり、接続の解放をガベージ コレクターに依存しないでください。実際、接続オブジェクトの reference が有効な範囲を超えた場合、接続は必ずしも閉じられるわけではありません。ガベージ コレクターの機能は、物理接続を表す .NET カプセル化オブジェクトを解体することですが、これは、基礎となる接続も閉じられます。

Close または Dispose メソッドを呼び出して、接続を解放して接続プールに戻します。接続オブジェクトは、有効期間が終了するか、重大なエラーが発生した場合にのみ、接続プールから削除されます。

1.4 接続プーリングとセキュリティ

アプリケーションのすべてのデータアクセス操作が同じ接続文字列を使用する場合、接続プールの利点は最大化されます。ただし、これは理想的な状況であり、アプリケーションの他の要件と矛盾する可能性があります。たとえば、接続文字列が 1 つだけ使用されている場合、データベース レベルでセキュリティ制御を強制することは困難です。

一方、各ユーザーが独自の接続文字列の使用を許可されている場合 (つまり、ユーザーごとに個別のデータベース アカウントが設定されている場合)、必然的に多数の小さな接続プールが存在し、多数の接続が存在します。全く再利用されません。従来、この種の問題に対する最善の解決策は、両極端の間の適切な妥協点を見つけることです。代表的なパブリック アカウントのセットを設定し、ユーザー ID を表すパラメーターを受け入れるように ストアド プロシージャ を変更することができます。ストアド プロシージャは、受信したユーザー ID に基づいてさまざまな操作を実行します。

2. トランザクションモデル

分散エンタープライズアプリケーションはトランザクションから切り離せません。データ アクセス コードにトランザクション管理機能を追加するには、主に手動と自動の 2 つの方法があります。

手動の方法では、プログラマーはトランザクションメカニズムを構成して使用するすべてのコードを記述する責任があります。自動 (または COM+) トランザクションは、.NET クラスに宣言属性を追加して、ランタイム オブジェクトのトランザクション特性を指定します。自動化されたアプローチにより、複数のコンポーネントを同じトランザクション内で実行するように構成することが容易になります。どちらのトランザクション方法もローカル トランザクションまたは分散トランザクションをサポートしていますが、自動トランザクション方法では分散トランザクション処理が大幅に簡素化されます。

トランザクションは非常にコストのかかる操作であるため、トランザクションの使用を決定する前によく考えなければならないことに注意する必要があります。本当にトランザクションを使用する必要がある場合は、トランザクションの粒度を減らし、データベースのロック時間とロック範囲を減らすようにしてください。たとえば、SQL Server の場合、単一の SQL ステートメントでトランザクションを明示的に宣言する必要はありません。SQL Server は各ステートメントを独立したトランザクションとして自動的に実行します。手動ローカル トランザクションは、DTC (分散トランザクション コーディネーター) を必要としないため、常に他のトランザクションよりもはるかに高速です。

手動トランザクションと自動トランザクションは、2つの異なる、相互に排他的な技術として見なされるべきです。単一データベースに対してトランザクション操作を実行する場合は、手動トランザクションを優先してください。単一のトランザクションが複数のリモート データベースにまたがる場合、または単一のトランザクションに複数のリソース マネージャーが関与する場合 (たとえば、1 つのデータベースと 1 つの MSMQ リソース マネージャー)、自動トランザクションが優先されます。いずれにせよ、2 つのトランザクション モードを混在させることはできる限り避ける必要があります。パフォーマンスが特に重要でない場合は、1 つのデータベース操作のみでも自動トランザクションを使用することを検討して、コードをクリーンにします (ただし、若干遅くなります)。

つまり、データベース アクセス コードの品質を向上させるには、ADO.NET オブジェクト モデルを深く理解し、実際の状況に応じてさまざまなテクニックを柔軟に使用する必要があります。 ADO.NET はパブリック API であり、Windows フォーム アプリケーション、ASP ページ、Web サービスなど、さまざまなアプリケーションが ADO​​.NET を通じてデータベースにアクセスできます。ただし、ADO.NET は入力の受け入れと結果の出力を同時に行うことはできません。 . ブラックボックスですが、たくさんのツールで構成されたツールボックスです。

以上がADO.NETの実践例の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。