È meglio inviare un evento o più eventi per le chiamate remote?

Question

È meglio inviare un evento o più eventi per le chiamate remote?

#1 da (3 voti)

3

In ActionScript la classe URLLoader che ha sette distinti eventi che possono verificarsi dopo aver chiamato il metodo load ().

Nel HTTPServive le classi ci sono due eventi, fault e result .

In una delle classi che ho scritto c'è solo un evento, result . Nell'evento risultato ho un successo di proprietà impostato su true o false e se true l'evento ha set di proprietà aggiuntive. Se falso ha un oggetto di errore impostato.

Per generalizzare, nella prima classe viene inviato un evento per casi molto specifici. Nella seconda classe ci sono solo due casi, successo o fallimento. Nell'ultimo è un evento che contiene, successo, fallimento, errori tutto in uno.

Ora sto leggendo sull'inferno del callback quando si tratta di chiamate asincrone e su come la funzione then può essere d'aiuto. Verrà richiamata una funzione di callback riuscita o non riuscita sui risultati.

La mia domanda, quali sono i pro e i contro di scrivere una classe che invia molti eventi molto specifici contro la spedizione di un minor numero di eventi e cosa vorresti usare quotidianamente come sviluppatore?

Nota: questo è indipendentemente dalla lingua e dall'approccio one one per gestire più casi o più gestori per gestirli singolarmente.

callbacks event-programming

posta 1.21 gigawatts 24.02.2017 - 05:40

fonte

1 risposta

Leggi altre domande sui tag callbacks event-programming

Progettare un'implementazione efficiente di una coda di accesso casuale basata su una lista collegata Consegna continua, compilare una volta o creare per ambiente

score 3 · Answer 1

Tutti questi approcci sono validi, coprono diversi casi d'uso.

L'evento definisce un momento in cui qualcosa accade. Il gestore definisce un tipo di informazioni associate a un determinato evento.

In questo senso, sia i gestori di successo che quelli di fallimento gestiscono un evento: l'arrivo dei risultati. I risultati di successo e fallimento si escludono a vicenda e rappresentano un caso speciale di gestione degli eventi: non ha quasi sempre senso gestire un risultato lasciando un altro non modificato. Ciò a sua volta significa che un'API corretta non consentirebbe la registrazione di una senza l'altra. Un buon esempio di tale API sono Promises che gestiscono sempre in modo implicito il caso di errore.

Naturalmente, i risultati non esclusivi non sono soggetti a tale trattamento e pertanto sono gestiti da gestori designati registrati separatamente. Ad esempio, potresti voler essere avvisato solo dell'arrivo del documento finale e non iscriverti alle notifiche di progresso.

È perfetto avere un solo handler, questi gestori sono spesso usati nei framework di Databinding, dove gli errori terminano l'elaborazione fermando la propagazione dell'evento, senza dover aggiornare i valori derivati.

Raggruppa i tuoi gestori da un momento in cui il loro evento si verifica (di solito ogni gruppo si escluderebbe a vicenda) fornendo un'API per registrare i gestori per ciascun gruppo. Fornisci un gestore per risultato, in modo che non disponga di un dispatch sul tipo di oggetto evento all'interno dei gestori.