0

SProc からの結果をテキストファイルに書き込もうとしています。3 つのシナリオがあります。

  1. SProc はパラメーターを取りません。

  2. SProc はパラメーターを取ります。

  3. SProc はパラメーターを取り、パラメーターをインクリメントするループがあります。

シナリオ 1 と 2 のデータは、1 行の結果である可能性が最も高いため、リストに格納されます。

シナリオ 3 のデータはデータ テーブルに格納されます。

これにはファクトリ パターン、それぞれが特定のインターフェイスを実装する 3 つの異なるクラス、および 3 つのうちどれが必要かを判断するためのファクトリを使用することを考えていました。

問題は、メソッドが終了し、完了イベントが発生した後、実装されたシナリオ (データテーブルとリスト) を知る必要があることです。これは問題ですか? もしそうなら、誰かが理由と可能な解決策を説明してもらえますか?

注：明確にするために、これは嘆願ではありません。私のプログラムを書いてください。

お時間をいただき、誠にありがとうございました。

4

1 に答える 1

2

インターフェイスの背後にある実際の型を知る必要があるときはいつでも、インターフェイスを導入するために間違ったポイントを選択した可能性があります。こちらはこんな感じです。

結果をログに記録するロジック (この場合はテキスト ファイルですが、他のターゲットが存在する可能性があります) からロジック (データを生成する) を実行することへの懸念を分離したいようです。ResultLogging のインターフェースを導入してみませんか?

interface IResultLogger
{
   void LogList(List<Something> data);
   void LogDataTable(DataTable data);
}

このインターフェイスのインスタンスを、ロジックを実行するすべてのメソッドに渡しますか?

これらのメソッド内に「ロギング」(IResultLogger インターフェイスの呼び出し) を行いたくない場合は、別の抽象化を追加することができます: 「ResultData」の概念です。

abstract class ResultData
{
   abstract public void LogToResultLogger();
   //add methods to access the data in a way you might need for other things in your program
}

「ListResultData」と「DataTableResultData」を導出します。

ここでは、ファクトリ パターンの価値はわかりません。

それを行う別の方法は、

class ListLogger
{
   public void LogList(List<Something> data) {}
}

と

class DataTableLogger
{
   public void LogDataTable(DataTable data) {}
}

そして、やります

void method1() and method2()
{
  //do logic
  new ListLogger().LogList(data);
}

void method3()
{
  //do logic
  new DataTableLogger().LogDataTable(data);
}
于 2012-06-29T08:08:07.430 に答える