Broadcasting - Ascolto delle risposte

Question

Broadcasting - Ascolto delle risposte

#1 da (1 voti)

4

Usiamo JS a proposito, ma penso che sia un linguaggio agnostico. Sono aperto alle idee.

Abbiamo questa struttura "pub-sub" che usiamo al lavoro per risolvere il problema del codice strettamente accoppiato. Funziona bene. I moduli ascoltano gli eventi, le cose corrono, trasmettono eventi, altre cose corrono. È fantastico. Tuttavia ...

Ad esempio, volevo cliccare su un link per aprire una modal, modificare i dati passati e inviarlo al chiamato. L'invio al modale sarebbe semplice come trasmettere un evento con i dati. Modale, sottoscritto all'evento, risponde e altera i dati. Il problema è riportare i dati al chiamante.

Scenari:

Il modulo trasmette un evento e allo stesso tempo ascolta un evento nella speranza di una risposta (evento di un altro modulo). Come potrei sapere che la risposta era in effetti dell'evento che è stato trasmesso poco prima di esso?
Un altro è che ho in programma di inviare una funzione di callback con i dati inviati attraverso l'evento. In questo modo, i ricevitori possono semplicemente chiamare il callback con i dati dalla loro parte. Tuttavia, il modulo riceverebbe una quantità sconosciuta di chiamate di richiamata, a seconda del numero di abbonati.

Lo scenario è più di messaggistica diretta, che è in qualche modo in contraddizione con la natura incendia e dimentica di una trasmissione. Ci sono dei modelli che mantengono ancora l'accoppiamento, la modularità e il tipo di architettura "sconosciuto all'altro"?

design architecture software

posta Joseph 20.06.2014 - 12:34

fonte

1 risposta

Leggi altre domande sui tag design architecture software

Sincronizzazione programmatica con server remoti Problemi con l'esposizione delle proprietà di classe tra i progetti

score 1 · Answer 1

Stai fondamentalmente usando un modello di mediatore. Per iniziare, tieni presente che potresti usarlo troppo spesso se lo stai utilizzando ovunque. I programmi guidati dagli eventi possono essere più difficili da eseguire il debug o anche prevedere in modo affidabile il comportamento, quindi ti consigliamo di utilizzare questo modello solo quando c'è un vero dolore causato dall'accoppiamento normale. Per un modale dubito strongmente che lo userei.

Detto questo, se vuoi continuare con questo, non c'è niente di sbagliato nell'avere un editore in ascolto su un nuovo evento unico e poi inviare informazioni su quale evento è in ascolto quando viene pubblicato. In questo modo il destinatario sa quale evento attivare, e poiché è unico, l'editore sa da chi proviene quando riceve l'evento. Quello che stai facendo in effetti è la creazione di un evento privato usato una sola volta dal publisher e dal sottoscrittore.

Se invece vuoi andare con la soluzione del tipo callback, considera l'idea di indagare sulle promesse di javascript. Piuttosto che dire "ecco una funzione che devi eseguire quando hai finito", promette di dire "dimmi quando hai finito e deciderò cosa fare".