0

シナリオ

システムの主要なコンポーネントが 3 つあるとします。

  1. UI - ユーザーからの入力を収集し、メッセージ バス経由で送信されるLoginUserCommandを作成します。次に、ユーザー インターフェイスはMessageReceivedEvent(s) のこのメッセージ バスをリッスンします。

  2. ユーザー サービス- LoginUserCommand を受け取り、UserLoggedInEventを発生させます。ここで重要なのは、Message Serviceにメッセージの受信を開始するように指示する必要があるということです。

  3. Message Service -ログインしているユーザーに対してMessageReceivedEventを発生させます。

オプション

私が持っている設計上の質問は、User ServiceとMessage Serviceの間の相互作用に関するものです。

ユーザーがログインすると、さまざまなことが発生する必要があります。UI がメッセージを受信し始めるように、サービスを調整する必要があります。

するべきか...

  • ユーザー サービスにUserLoggedInEventを発生させ、メッセージ サービスにこのイベントをリッスンさせ、ユーザーがメッセージを受信するために必要な作業を実行させますか?

...また...

  • ユーザー サービスにUserLoggedInEventを発生させますが、コマンド - StartMessageRecomingCommand を作成し、これを明示的にメッセージ サービスに送信しますか?

質問

各アプローチの長所と短所は何ですか? (カスケード イベントと明示的なコマンド)。他のオプションはありますか？

4

2 に答える 2

1

サービスが実際のサービスである場合は、userloggedinevent を発生させて、「メッセージ サービス」に次に何をするかを決定させます。ユーザーサービスは、ユーザーがログインした場合にメッセージの受信を開始する必要があるメッセージサービスについての知識を持つべきではありません。イベントを発生させ、すべてのサブスクライバーが次に何をすべきかを自分で決定できるようにします。

于 2012-08-10T09:23:26.780 に答える
0

これは私にはあまり意味がありません。UI 自体は論理的なサービスではありません。

Message ServiceMessageReceivedEventによって公開されたメッセージは、UI がそのフィードをサブスクライブできるほど十分に公開されていますか? そうでない場合は、これらのメッセージをまったく公開しないでください。

MessageReceivedEventユーザーがログインしていない限り s の処理を​​許可されていない場合、これが起こらないようにするのはユーザー/セキュリティ サービスの責任です。

MessageReceivedEvent実際に公開する必要がある場合、 UIプロセスでユーザー サービスを実行しないのはなぜでしょうか?

  1. UIプロセスがサブスクライブする (メッセージ サービスにサブスクリプション要求を送信する)MessageReceivedEvent
  2. UIは、ユーザー サービスLoginUserCommandの remtoe エンドポイントに を送信し、ローカルで処理しますUserLoggedInReply
  3. UIプロセス MessageReceivedEventには 2 つのハンドラーがあります。
    • 最初のハンドラーはユーザー サービスに属し、ユーザーがログインしていない場合は bus.DoNotContinueDispatchingCurrentMessageToHandlers() を呼び出します
    • MessageReceivedEvent2 番目のハンドラーは、実際にsで何か役立つことを行う他のサービスに属しています。

ステップ 3 で、ユーザーがログインすると、最初のハンドラーは何もしません。ユーザーがログインしていない場合、最初のハンドラーは他のMessageReceivedEventハンドラーの実行をまったく停止します。

ここでメッセージの順序を指定することについての詳細があります

お役に立てれば

于 2012-08-12T08:34:03.497 に答える