2012-12-19 8 views
5

私はクラスChatManagerを持っていますが、その中にChatServerChatClient(WCF)クラスがあります。サブスクリプションするイベントのバブリング

私はChatManagerをインスタンス化し、私のコントローラはChatClient上にあるUserConnectedUserDisconnectedMessageReceivedイベントにサブスクライブすることができるようにしたいです。

これを行う最もエレガントで論理的な方法は何ですか?私が持っているのと同じようにChatClientのイベントを定義してから、ChatManagerのイベントをコントローラーに渡すだけで、ChatClientを処理したり知ったりすることなくイベントを再定義するのは愚かですか? ChatManagerChatClientのイベントに登録してから、ChatControllerが聴いているイベントを開始します。

WPFはイベントのバブリングという概念を持っていますが、それがこのタイプのシナリオ用であるかどうかは分かりません。何もユーザーインターフェイスの一部ではないためです。

答えて

2

を私はChatManagerChatControllerの両方が正当化できるかどうかを問うことから始めたいです彼ら自身の存在。一般的に、 "マネージャ"クラスを作成するときはいつも、本当に必要ではありません。特に、メッセージの一部がメッセージを中継するだけの場合は特にそうです。

コントローラクラスは、SRPの「責任」が非常に広いので、SRPと闘うことができます。特定の動作に対する責任を委任したい場合は、ChatClientの責任をコントローラに残し、ChatClient(契約インタフェースを介して)を使用して従属コントローラを初期化し、必要に応じてクライアントと対話できるようにします。あなたが部下やクライアントを破棄する前にそれらのイベントの登録を解除するイベントの登録を開始するときは、管理されたメモリリークを確認してください。

+0

スティーブ、私は両方の存在の正当性について正しいかもしれないと思います。もともと私はすべてのサーバーコードとすべてのクライアントコードをマネージャークラス自体に持っていました。私は最近、そのすべてを2つの別々のクラスにリファクタリングしました。マネージャーは単にサーバーを起動し、サーバーとクライアントをインスタンス化してサーバーに参加する手段にすぎません。 私は今チャットマネージャーを取り除き、コントローラーにそのすべてをさせるのが最良の方法だと思います。コントローラがあまりにも肥大化するかどうかは不思議ですが。しかし、論理的にはその責任に当てはまると思います。 – Cowman

+0

+1が同意しました。これが起こるときはいつでも、それに疑問を呈してください。 – nycynik

0

条件付きでイベントを購読する(または複数のハンドラで順番に処理する)必要がある場合を除き、「バブリング」は必要なものではありません。 event aggregatorを使用するのがおそらく最善の方法でしょう。

+0

まあ、イベントアグリゲータを持つPrismを使用しています。イベント集約のためのモデルに依存関係を作成することは理にかなっていますか?今、私のChatManagerはPrismについて何も知らない。 – Cowman

+0

@Cowmanそれは私が考えると思われるいくつかの要因に依存します。 1)ChatManagerを含むライブラリがPrismを使用せずに使用される場所はありますか?2)依存関係を弱める方法があるかどうか(ChatManagerのイベントアグリゲータへのインターフェイスのみを使用し、 ) – mlorbetske

1

あなたが探しているバブリングイベントではありません。あなたが簡単にあなたの親(ChatManager)に子クラスのインスタンスを呼び出し、そのようなイベントをサブスクライブすることによって、これらのイベントをサブスクライブすることができます

chatManager.UserConnected += (param1, param2) => { 
    //your code here 
}; 
+2

匿名の代理人とのイベントの配線は、ガベージコレクションされないインスタンスで終わる優れた方法です。 –

+0

合意。これは単なる基本的な実装です。そのようなことを処理するよりエレガントな方法があります。 –

関連する問題