2

次の状況を想像してみてください。Windowsサービスは、データベーステーブルのデータを随時チェックします。新しいデータが表示されると、新しい各行の処理が開始されます。

処理はいくつかの論理的な段階で構成されています。

  • Webサービスからいくつかの追加データを取得します。
  • ステージ1のデータを使用して、Webサービスを介してexistinsオブジェクトを検索するか、新しいオブジェクトを作成します。
  • 実行されたアクションを関係者に通知します(ステージ2で検出/作成されたオブジェクトに関する詳細を含む)。
  • 他のsmthを行います。

今のところ、例外が発生した場合、サービスはDB行を更新し、間違いが発生したことを示すフラグを設定します。しばらくして、サービスは行をもう一度処理しようとします...そしてここに問題があります。

処理は最初からステージ1から開始されます。この場合、ステージ4で例外が発生し、それが何度も発生する場合は、ステージ3の関係者に何度も通知されます...

例外が発生した場合に行処理を完全に停止することは不可能であり、私の状況では望ましくありません。前回失敗した段階から処理を開始する方法があればいいのにと思います。

今、私はこれらすべてをどのように扱うことができるかについてあなたのアドバイスが必要です。実際、処理にはいくつかのパターンがあり、ステージの数も異なるため、すべてがさらに複雑になります。

前もって感謝します。

アップデート

はい、データ行にStateパラメータがあります:)今のところ使用されていません。そして、例外処理は私にとって新しいことではありません。

問題は、状態の切り替えを処理するための最良の方法は何ですか?言い換えれば、ステージ番号と処理方法の間に明確な論理リンクを作成するには?実行のフローは非常に異なる可能性があり、さまざまな行のさまざまな数のステージとメソッドが含まれます。

新しいsutiationごとに無限のswitch/caseブロックを作成するよりも、もっと楽しい方法があるといいのですが。

4

2 に答える 2

1

説明の各問題に役立つパターンがいくつかあります。

  1. Windows サービス チェック キュー。サービスに 1 分または 5 分ごとなどに実行されるタイマーを用意し、キューをチェックして、新しいエントリがあれば処理を開始します。(こちらの例を参照してください: Windows サービスで使用するのに最適なタイマー)
  2. 一連の手順に従うことは、一般にワークフローと呼ばれます。ワークフローには現在のステータスがあり、各ステージでそのステータスを更新します。したがって、すべての行はステージ = 1 で始まります。最初のステップの後、ステージ = 2 などです。例外として、中断したステージにあり、そのステージでプロセスを最初からやり直します。ロジックは。このステータスは各行に保存され、ディスパッチ コードはステータスをチェックして、現在のステージの正しい開始コードにサービスを送信します。Ifつまり、ステータスに基づいた一連のステートメントを考えてみてください。
  3. 例外の処理は非常に簡単です。すべての作業単位は、try...catch ブロックでラップする必要があります。エラーが発生した場合は、例外をログに記録し、ビジネス ルールに従って行をマークします。

実装に関しては、プログラミングのベスト プラクティスを使用して、コードをクリーンでモジュール化され、きちんと整理された状態に保ちます。ソリューションを開発するときは、特定の質問を元に戻して、さらに支援を求めてください。

于 2012-06-01T14:34:57.987 に答える
0

各行の状態を追跡するフィールドをデータベーステーブルに追加します。たとえば、この新しいフィールドProcessingStateを呼び出すことができます。

行が各論理状態を通過するときに、このProcessingStateフィールドを更新して、行がどの状態にあるかを識別できます。

サービスの各論理ステップは、適切な状態にある行を処理する必要があります。

これが例です。5つの論理的なステップを実行するとします。次の状態になる可能性があります。

  1. 待機状態1。
  2. 状態1完了
  3. 待機状態2
  4. 状態2完了

等..

幸運を。

于 2012-06-01T14:39:16.167 に答える