Event Handler e IObservable sono intercambiabili?

A quanto ho capito, lo schema Observable riguarda tradizionalmente il binding in tempo reale di un'interfaccia utente, in base alle modifiche nell'archivio dati sottostante. In altre parole, un'interfaccia utente che si iscrive a un IObservable<T> ha aggiornamenti che vengono trasferiti quando l'archivio dati sottostante cambia.

I gestori di eventi sono un meccanismo più generalizzato. Sono usati per tutti i tipi di cose, sia all'interno dell'interfaccia utente che altrove. Fondamentalmente, EventHandler<T> è in realtà solo una definizione formale per una firma delegata che è stata utilizzata sin dall'inizio di Windows Form.

Hai guardato Reactive Extensions? Reactive Extensions è una libreria che consente la composizione di codice aysynchronous e basato su eventi. Darei un'occhiata a Intro To Rx , ha molte informazioni su quando IObservable è appropriato e, come ha detto J Trana, uno dei vantaggi è una riduzione dell'accoppiamento.

Senza ulteriori informazioni sulla tua applicazione, è difficile consigliare specificamente quale approccio consiglierei.

Quando penso agli eventi, di solito penso a loro nel contesto di quanto siano strettamente accoppiati.

EventHandler style eventing è molto concreto e strettamente accoppiato. Ritengo che sia appropriato nello stesso tipo di situazioni che usereste una classe concreta contro un'interfaccia per qualcosa. È l'approccio "integrato" a .NET e ai mirror get / set sulle proprietà con add / remove. Assicurati di considerare il blocco all'interno del tuo Aggiungi / Rimuovi se segui questo percorso.

IObservable < T > gli eventi di stile sono meno concreti. Potresti avere uno o più oggetti che potrebbero essere passati in giro come lo stesso IObservable < T & gt ;. Fornisce inoltre un meccanismo di gestione degli errori e di completamento.

L'aggregazione di eventi è una terza opzione, una che io Ho usato e piaciuto. Fornisce un accoppiamento ancora più flessibile e aiuta gli abbonati e gli editori a ignorare i dettagli l'uno dell'altro. Semplifica anche gli eventi di distribuzione su diversi thread.

In generale, i meccanismi strettamente accoppiati sono semplici da scrivere e semplici da eseguire il debug, ma offrono meno flessibilità man mano che un'applicazione cresce. I meccanismi liberamente accoppiati sono ancora facili da scrivere, ma possono essere molto meno semplici da tracciare quando si guarda un codice base sconosciuto. In ogni caso, assicurati di comprendere anche la durata degli oggetti sottoscrittori quando implementi questi schemi (principalmente quelli strettamente accoppiati), poiché non lasciare cadere oggetti è una trappola. MSDN ha una piccola sezione sull'accoppiamento degli eventi.

Purtroppo, non vedo abbastanza descrizione del tuo programma per capire quale livello di accoppiamento hai bisogno, ma spero che questo ti aiuti a fare la scelta giusta.