Come interagiscono tra loro Event Bus e ReativeX?

Question

Come interagiscono tra loro Event Bus e ReativeX?

#1 da (1 voti)

-1

Volevo esaminare i modelli di comunicazione / disaccoppiamento e come migliorarli.

Il mio attuale approccio è di avere un comandante centralizzato nella forma di un bus eventi e farlo essere quello che risponde alla maggior parte delle interazioni esterne, come l'interfaccia utente o la rete. Ogni volta che si apre un nuovo evento, il callback del ricevitore invia un segnale al bus, che lo diffonde ai ricevitori. Il messaggio contiene tutti gli elementi contestuali necessari per rispondere a quel segnale, rendendo l'orchestratore ricevente che ha solo a che fare con l'elaborazione e il rendering di tali modifiche.

Example: my program is connected through a socket to a live stocks feed. Whenever a new stock arrives, it parses the payload into an object and signals the bus with it. My current window is subscribed for that event and whenever it gets signaled, it looks for the event payload in its internal list and applies any value changes on screen.

Una tecnologia nuova e brillante che sta ottenendo attenzione ultimamente è Reattiva. Se ho capito bene, in questo nuovo paradigma ogni informazione è considerata un flusso nel tempo, in cui abbiamo una componente osservabile a cui ci iscriviamo, e ogni volta che viene segnalata puoi semplicemente elaborarla. Questa informazione osservabile può essere referenziata (iniettata?) In tutte le classi che desideri.

Ci sono dei vantaggi da una prospettiva architettonica dall'usare ReactiveX con Bus?

object-oriented event-programming reactive

posta MLProgrammer-CiM 05.11.2014 - 14:04

fonte

1 risposta

Leggi altre domande sui tag object-oriented event-programming reactive

Serve aiuto nella creazione di un database di poligoni della mappa In un'applicazione MVC, qual è il modo corretto di organizzare i punti di ingresso per la business logic?

score 1 · Accepted Answer

Non è davvero una questione di uno o dell'altro. Possono essere facilmente combinati.

L'idea dietro i flussi reattivi (o qualunque cosa tu voglia chiamarli) non è esattamente nuova nel mondo funzionale. La motivazione alla base è quella di rendere la composizione facile. È possibile operare su flussi come sui valori. Ad esempio, puoi prendere il valore di un campo di testo e vederlo come uno stream, quindi trasformare quel flusso avendo ciascun valore da utilizzare come termine di ricerca su un determinato database di ricerca, quindi trasformare quel flusso di elenchi di risultati di ricerca in un flusso di Componenti dell'interfaccia utente e quindi utilizzare semplicemente lo stream come contenuto di una finestra. Quindi hai molte trasformazioni da un tipo di dati a un altro, che può essere scritto in completo isolamento e quindi lo si collega. I contratti sono piuttosto piccoli. Puoi facilmente sostituire il termine di ricerca - > trasformazione dell'elenco dei risultati di ricerca per un altro, che utilizza una cache o un altro database o una strategia di ricerca o cosa no.

L'idea che sta dietro agli event bus è che gli eventi possono viaggiare abbastanza liberamente attraverso il tuo sistema e rende facile collegare il comportamento a quegli eventi. Anche se questo può facilmente diventare un gran casino. In un certo senso, stai creando un sistema con caratteri generici qui. Non hai un modo semplice per sapere se gli eventi a cui ti sei iscritto sono mai stati caricati sul bus o se gli eventi attivati vengono mai consumati. O se un conflitto si verifica e così via. Quindi gli autobus di eventi hanno i loro punti di forza e di debolezza.

Tuttavia, i due concetti sono ortogonali. Puoi prendere uno stream e inserirlo in un bus degli eventi e puoi prendere eventi specifici da un bus degli eventi e generare uno stream da loro.

Quindi potresti dire che i flussi reattivi riguardano il modo in cui trasformi i dati in eventi e i bus eventi riguardano il modo in cui gli eventi passano da un sottosistema a un altro.