2012-12-19 15 views
5

Mam klasy ChatManager, który ma klasy ChatServer i ChatClient (WCF) wewnątrz nich.Bubbling up zdarzeń, które mają być subskrybowane

Chcę mojego kontrolera który instancję ChatManager aby móc zapisać się na UserConnected, UserDisconnected i MessageReceived wydarzeń, które są na ChatClient.

Jaki jest najbardziej elegancki i logiczny sposób na zrobienie tego? Czy jest głupio dla mnie zdefiniowanie zdarzeń w takim stanie, jak ja, a następnie zdefiniowanie na nowo wydarzeń w ChatManager wyłącznie po to, aby przekazać zdarzenia do kontrolera, bez konieczności radzenia sobie z nim lub bez wiedzy o tym, co się dzieje z ChatClient? ChatManager zasubskrybuje zdarzenia z ChatClient, a następnie odpali swoje własne zdarzenia, które będą nasłuchiwać.

Wiem, że WPF ma pojęcie bulgotania zdarzeń, ale nie wiem, czy to jest dla tego typu scenariusza, ponieważ nic nie jest częścią interfejsu użytkownika.

Odpowiedz

2

bym zacząć od kwestionowania czy zarówno ChatManager i ChatController może zarówno uzasadnić ich własne istnienie. Generalnie za każdym razem, gdy tworzysz klasę "Menedżer", nie jest to konieczne, szczególnie jeśli część tego, co robi, składa się tylko z przekazywania wiadomości.

Klasy kontrolerów mogą walczyć z SRP, ponieważ ich "odpowiedzialność" jest dość szeroka. W przypadkach, w których chcesz przekazać odpowiedzialność za pewne zachowanie, pozostaw odpowiedzialność za sterownik ChatClient i zainicjuj podrzędny kontroler za pomocą ChatClient (poprzez interfejs kontraktowy), aby mógł on w razie potrzeby współdziałać z klientem. Po prostu upewnij się, że po rozpoczęciu rejestrowania zdarzeń, które wyrejestrują te zdarzenia przed odrzuceniem podwładnych lub klienta, w przeciwnym razie będziesz szukał zarządzanych wycieków pamięci.

+0

Steve, myślę, że możesz mieć rację co do uzasadnienia istnienia obu z nich. Pierwotnie miałem cały kod serwera i cały kod klienta w samej klasie menedżera. Niedawno refaktoryzowałem to wszystko na dwie oddzielne klasy, a menedżer jest jedynie środkiem do uruchomienia serwera i dołączenia do serwerów poprzez utworzenie instancji serwera i klienta. Myślę, że jest to najlepszy ruch, aby pozbyć się teraz "ChatManager" i mieć kontroler, który to wszystko robi. Chociaż zastanawiam się, czy to spowoduje, że kontroler będzie zbyt rozdęty. Ale myślę, że logicznie leży w jej obowiązkach. – Cowman

+0

+1 uzgodniony. Za każdym razem, gdy to się dzieje, dobrze jest to zakwestionować. – nycynik

0

Jeśli nie potrzebujesz, aby zdarzenie tylko warunkowo dotarło do rzeczy, które by go subskrybowały (lub by były przetwarzane sekwencyjnie przez wiele programów obsługi), "bulgotanie" nie jest czymś, czego powinieneś potrzebować. Korzystanie z event aggregator będzie prawdopodobnie najlepszym sposobem.

+0

Cóż, używam pryzmatu, który ma agregator zdarzeń. Czy ma sens tworzenie zależności w modelu dla agregacji zdarzeń? Teraz mój ChatManager nic nie wie o Pryzmie. – Cowman

+0

@Cowman To zależy od kilku czynników, które myślę. 1) Czy jest kiedykolwiek miejsce, w którym biblioteka zawierająca ChatManager byłaby używana bez użycia Prism 2) Czy istnieje sposób na osłabienie zależności (np. Użycie tylko interfejsu do agregatora zdarzeń w ChatManager i posiadanie czegoś spełniającego zależność od niego?) – mlorbetske

1

To nie jest reklama bąbelkowa, której szukasz. Możesz łatwo zapisać się do tych wydarzeń poprzez wywołanie instancję klasy podrzędne w swojej dominującej (ChatManager) i subskrybowania Zdarzenia tak:

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

Okablowanie zdarzeń z anonimowymi delegatami to doskonały sposób, aby skończyć z instancjami, które nie zostaną zebrane. –

+0

Uzgodnione. To tylko podstawowa implementacja. Istnieją bardziej eleganckie sposoby radzenia sobie z takimi rzeczami. –

Powiązane problemy