0

私のシステムは、個別のハンドラーでコマンドパターンを使用しています。私のコマンドは、現在処理中のすべてのコマンドを処理するCommandServiceで実行されます。

遅い操作であるこれらのことの少なくとも1つを実行する特定のコマンドがあります：

  1. メールを送信します
  2. PDFを生成します
  3. ファックスを送信します
  4. サードパーティのWebサービスと対話します

UIがよりスッキリするように、これらのコマンドをすべてアウトプロセスで処理する必要があります。

これらのコマンドだけにメッセージングバスを使用する必要がありますか、それともインプロセスコマンドハンドラーを呼び出す必要がありますBeginInvoke()か？

編集-追加情報

システムのユーザー数は少ないため（忙しい日に同時に100人になる可能性があります）、キューが長くなることはほとんどありません。ここでの主なことは、PDFが添付された電子メール（問題のコマンド）を送信するときにUIがブロックされる時間を短縮することです。従業員はそのコマンドを1日に何度も実行する必要があります。

BeginInvoke()全体的な状況を念頭に置いて、私はいくつかの理由で今のところ行くつもりだと思います：

  1. コマンドが成功したかのように動作することを確認するには、すべてのUIインタラクションに触れる必要があります。「このドキュメントを送信する必要があります」というリマインダーはUIの複数の場所にあり、レポートが送信されるとページ全体が更新されます。
  2. クライアントの忙しい季節の真っ只中です（夏には年間ビジネスの50％以上を行っています）。そのため、現時点では、管理に慣れていないまったく新しいインフラストラクチャを導入するのは賢明ではないようです。 。

しかし、私が今知っていることを知っていると、新しいシステムでは、遅いコマンドには最初からサービスバスを使用し（事実上すべてのシステムが電子メールを送信する必要があります）、コマンドを同期からより簡単に切り替えることができるようにUIを設計します非同期処理に。実装では、これは基本的にすべてのPOSTがAJAXであり、成功したかのようにUIでアクションを実行することを意味します。（この例については、Facebookがコメントを処理する方法を確認してください。）

4

2 に答える 2

2

それはおそらくあなたをメッセージバスに向かわせる信頼性の問題です。元のトランザクション（BeginInvokeを実行したトランザクション）が成功し、呼び出しの途中でサーバーがクラッシュした場合、システムには、電子メールの送信やPDFの生成が必要なメモリがありません。 。

メッセージバスは、その2番目のトランザクションをキューにロールバックできるため、サーバーが再起動すると、サーバーは再び電子メールを送信します。

于 2012-07-29T07:15:13.997 に答える
2

どちらのソリューションにも長所と短所があります。

  • BeginInvokeは非常に単純なソリューションであり、そのセマンティクスは、コマンドでハンドラーを直接呼び出すのと同じです。ただし、このソリューションはスレッドインフラストラクチャに依存します。最大スレッド数、IOリソースへの同時アクセスによるフリーズスレッドなどです。
  • MessageBusは非常に柔軟で強力なソリューションであり、コマンド処理プロセスのあらゆる側面を制御できます。ただし、アプリケーションに別の抽象化レイヤーが導入されます。これは、単純な方が優れている場合にオーバーエンジニアリングになる可能性があります。

システムの負荷要件、これらのバックグラウンドタスクの数、成長要因などを見積もり、それに応じて決定することをお勧めします。

しかし、私の個人的な意見では、ケースの80％に適合するバスソリューションを紹介しています。必要に応じて、次の反復で拡張できる単純なバス実装を導入できます。

于 2012-07-27T23:14:21.747 に答える