1

作業スレッドで SQL バッチを開始するメイン UI スレッドがあります。

バッチは、いくつかのエラー (ブロッキング) または警告 (非ブロッキング) を生成する場合があります。

最初のケースでは、最終的にトランザクションをロールバックしてスレッドを終了します。

2 番目のケースでは、ユーザーに SQL バッチの途中で警告メッセージを確認してもらいます。

  1. 一部のデータは処理されます
  2. いくつかの警告が生成されます
  3. ユーザーがこれらのメッセージをレビューします
  4. ユーザーはバッチを続行するか停止するかを決定します
  5. バッチの再開または停止

作業スレッドから直接作成することもできますがShowDialog()、これは UI スレッドではないため、このソリューションは好きではありません。

私のアイデアは、メイン UI スレッドに状況を通知し ( 「警告が生成されました」 )、作業スレッドを一定時間 (たとえば 500ms) スリープさせることでした。トライステート ( bool?) は、スレッドが起動するたびにチェックされます。値がない場合、スレッドは再びスリープ状態になります。

ユーザーが警告を確認し、場合によっては続行することを決定すると、ブール値が設定され、次に作業スレッドが起動したときに、続行するか、バッチを安全に中止 (ロールバック) するかがわかります。

これはとても悪いデザインパターンですか？

4

3 に答える 3

4

「起床」の仕組みを変えればコンセプトは悪くない。

bool?と定期的にワーカーを独自に起動する代わりに、と を使用することboolをお勧めしますManualResetEvent。ワーカーは UI に通知し、イベントを待機します (すぐにブロックします)。UI はユーザーとやり取りし、 をbool適切に設定して、イベントを通知します (値を検査し、それに応じて動作するワーカーを解放しboolます)。

もちろん、上記はさまざまな方法で実装でき、実装にはエンジニアリングの余地がかなりあります。スケールの一方の端では、生のフラグとイベントをコードに密結合することができ、もう一方の端では、ワーカーがクエリを実行する抽象的な "フィードバック サービス" を使用できます。

これにより、フィードバック サービスの 1 つの実装を別の実装に交換できるようになり、とりわけ次のことが可能になります。

  1. 「すべての警告に対してこれを行う」オプションを提示します。選択されている場合、フィードバック サービスはリクエストの UI の表示を停止し、代わりに内部で応答します。
  2. 「サイレント モード」での操作の実行: フィードバック サービスは、UI を表示せずに要求に応答するように構成されています (たとえば、常に「続行」と言う)。
于 2013-06-07T09:06:57.197 に答える
2

これを行うには、イベントを使用します。このような：

  1. クラス メンバー変数として AutoResetEvent を作成する
  2. 使用インタラクションが必要な場合は、最初にイベントをリセットします
  3. メイン UI スレッドに通知する
  4. イベントを待つ

メインスレッドで：

  1. 警告/エラーを表示します。
  2. ユーザーが選択したものを保存します。
  3. イベントを設定します。

ここで、ワーカー スレッドが起動し、メイン スレッドの結果 (ユーザーが選択したもの) を取得して続行します。

于 2013-06-07T09:07:47.333 に答える
1

を使用する代わりに、bool?ロック機構を使用してみませんか? ManualResetEventたとえば、ユーザーが決定するまでスレッドをブロックできます。彼の決定により、このイベントが設定され、スレッドが作業を続行する可能性があります。ブロックのメカニズムと実行の継続方法に関する情報を明確に区別するために、動作を継続する方法を別の変数に渡す必要があります。

于 2013-06-07T09:08:22.243 に答える