StatefulService contra ICommunicationListenerの責任

Question

ステートフルサービスのメッセージを受信するためにサードパーティのメッセージングシステムを使用します。だから私はICommunicationListenerインターフェイスと既存のサンプルを見始めた。しかし、ほとんどの例では、通信リスナ内で直接的または間接的にインバウンドメッセージを処理するので、何をすべきかは不明です。インバウンドメッセージをサービスに渡す方法が見つかりません。

このため、ICommunicationListenerインターフェイスまたはCreateServiceReplicaListenersメソッドが存在する理由には意味がありません。サービス自体には、既にリスナーの作成方法と構成方法に関する知識がすべて備わっています。したがって、特定のインターフェイスを実装することなく、独自のリスナーをステートフルサービス（コンポジションを使用）に直接設定することができます。

複雑さの追加層は何を追加しますか？

Answer 1

ここではcustomの実装例がICommunicationListenerです。受信メッセージを処理するinstanceのIServiceBusMessageReceiverを渡します。

Answer 2

私もこれで苦労しました。私の意見では、ICommunicationListenerという名前は、ほとんどの場合、リスニング/コミュニケーションを行う「事」ではないという点で、誤解を招きます。ただし、機能を抽象化し、実際の通信チャネルの開始、停止、中止のメソッドを定義しています。これにより、サービスファブリックサービスは、実際の通信チャネルとは独立した起動およびシャットダウンが可能になります。また、サービスが突然シャットダウンした場合でも、通信チャネルを正常にシャットダウンすることができます。

多分答えではありませんが、コメントのために長くしていたかもしれません。