0

私は、クライアントが特定のデータソースからデータを取得するために使用できるクラスを作成するように任命されました。たとえば、メインルーチンは次のようになります

IDataReader GetDataReader(DbCommand command);
DataSet GetDataSet(DbCommand command);

Data Access Applicationブロックがこれを行うことは知っていますが、説明しない理由でアプリケーションブロックを使用できません。とにかく、私はいくつかのロジックを借りるつもりです。

ただし、私のタスクのもう1つの部分は、開いているDataReaderを追跡することです。これは、すべての人がリーダーを適切に閉じていることを確認するためだけに必要です。私の計画は、この新しいクラス内にDataReaderのコレクションを含めることでした。これは、GetDataReaderルーチンが呼び出されるたびに追加されます。アプリの実行が終了すると、コードはこのコレクションを通過し、まだ​​開いている各リーダーのファイルに警告を記録します。

だから、私は2つの質問があります：

  1. このデザインに本質的に何か問題がありますか？
  2. とにかく、DataReaderからSQLコマンドを実行することはできますか？これにより、閉じていないリーダーの検索が大幅に簡素化されます。または、この情報を取得するためにリーダーとコマンドのペアを保存する必要がありますか？
4

1 に答える 1

2

ルールを適用するために、データ アクセス コンポーネントをもう少し高いレベルにすることを検討しましたか? たとえば、get-in-get-your-data-and-get-out-and-close ポリシーを適用するには、データ アクセス コンポーネントからデータ セットとスケーラーのみを返します (また、ストアド プロシージャのみを使用するなどの他のルールも適用します)。データベースと対話します)。呼び出し元が実際にはデータのみを必要とし、データ リーダーはあまり必要としない場合は、おそらくリーダーからデータを読み取ってから閉じることができるため、リーダーの状態を追跡する必要はありません。

DataReader を返す技術的な必要性がある場合 (多くの場合)、生のリーダーを返すのではなく、ラッパー クラスまたはリーダーのサブクラスを作成し、代わりにそれを返すことができます。たとえば、TrackedDataReader などです。次に、ブックキーピングをクラス自体に組み込むことができます。ちょっとした考え。

于 2009-06-10T18:54:03.887 に答える