2012-12-19 12 views
5

Ho una classe ChatManager, che ha una classe ChatServer e una classe ChatClient (WCF) al loro interno.Bubbling up eventi da sottoscrivere a

Voglio il mio controller, che crea un'istanza della ChatManager di essere in grado di iscriversi agli eventi UserConnected, UserDisconnected e MessageReceived che sono sul ChatClient.

Qual è il modo più elegante e logico per farlo? È sciocco da parte mia definire gli eventi nello ChatClient come ho fatto io, e quindi ridefinire gli eventi nel ChatManager unicamente per passare gli eventi al Controller senza che debba occuparsi o sapere dello ChatClient? Lo ChatManager si iscriverebbe agli eventi dello ChatClient e quindi avrebbe attivato i propri eventi che sarebbero stati ascoltati da ChatController.

So che WPF ha il concetto di bubbling di eventi, ma non so se questo è per questo tipo di scenario, dal momento che nulla è parte di un'interfaccia utente.

risposta

2

mi piacerebbe iniziare mettendo in discussione se sia ChatManager e ChatController grado sia di giustificare la propria esistenza. Generalmente ogni volta che ti trovi a creare una classe "Manager", non è davvero necessario, specialmente se parte di ciò che sta facendo consiste semplicemente nel trasmettere messaggi.

Le classi di controller possono lottare contro SRP poiché la loro "responsabilità" è piuttosto ampia. Nei casi in cui si desidera delegare la responsabilità per determinati comportamenti, lasciare la responsabilità per lo ChatClient con il controller e inizializzare un controller subordinato con ChatClient (tramite un'interfaccia del contratto) in modo che possa interagire con il client in base alle esigenze. Assicurati solo che quando inizi a registrare eventi che deselezioni quegli eventi prima di scartare i subordinati o il cliente, altrimenti guarderai le perdite di memoria gestite.

+0

Steve, penso che potresti avere ragione riguardo alla giustificazione dell'esistenza di entrambi. Originariamente avevo tutto il codice server e tutto il codice client nella classe manager stessa. Di recente ho quindi effettuato il refactoring di tutte le due classi separate e il gestore è semplicemente un mezzo per avviare il server e unire i server istanziando il server e il client. Penso che sia la mossa migliore per sbarazzarsi di 'ChatManager' ora e fare in modo che il controller faccia tutto. Anche se mi chiedo se renderà il controller troppo gonfio. Ma immagino che logicamente ricada nelle sue responsabilità. – Cowman

+0

+1 concordato. Ogni volta che succede, è bello metterlo in discussione. – nycynik

0

A meno che non si abbia la necessità che un evento raggiunga solo condizionatamente le cose che lo sottoscrivono (o che vengano elaborati sequenzialmente da più gestori), "bubbling" non è realmente qualcosa che si dovrebbe avere. Utilizzare un event aggregator sarebbe probabilmente il modo migliore per andare.

+0

Bene, sto usando Prism, che ha un aggregatore di eventi. Ha senso creare una dipendenza nel modello per l'aggregazione di eventi? In questo momento il mio ChatManager non sa nulla di Prism. – Cowman

+0

@Cowman Dipende da un paio di fattori che penserei. 1) C'è sempre un posto dove la libreria contenente ChatManager sarebbe usata senza usare Prism 2) C'è un modo per rendere debole la dipendenza (cioè usando solo un'interfaccia all'aggregatore di eventi in ChatManager e qualcosa che soddisfa la dipendenza per esso) – mlorbetske

1

Non si tratta di eventi bubbling che stai cercando. Si può facilmente iscriversi a questi eventi chiamando un'istanza della classe bambino in un genitore (ChatManager) e la sottoscrizione di Eventi in questo modo:

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

Il cablaggio di eventi con delegati anonimi è un ottimo modo per finire con le istanze che non saranno raccolte. –

+0

concordato. Questa è solo un'implementazione di base. Ci sono modi più eleganti per gestire queste cose. –

Problemi correlati