Ho trascorso la maggior parte dell'ultimo anno di programmazione in Silverlight, il che significa che ho passato molto tempo a riflettere (e a combattere) con gli stessi problemi che stai descrivendo.
In breve, come altri hanno sottolineato, la vera forza del modello asincrono è la sua capacità di creare sistemi robusti che interagiscono bene con il mondo reale. Nessuno potrebbe realisticamente utilizzare un'applicazione Silverlight (o Flash) se il thread dell'interfaccia utente si arrestasse ogni volta che sono necessari alcuni secondi prima che una chiamata al servizio web tornasse.
Il più grande svantaggio è che il codice risultante è complesso e difficile da risolvere. Cose come la gestione degli errori sono un PITA, ma le cose più fastidiose che ho dovuto affrontare sono il coordinamento delle risposte da più chiamate asincrone. Se, per esempio, hai bisogno di informazioni dalla chiamata A prima di effettuare la chiamata B, e hai bisogno di informazioni dalla chiamata B prima di effettuare la chiamata C (e così via), il codice risultante appare davvero sgradevole ed è suscettibile a tutti i tipi di strani effetti collaterali . Ci sono tecniche per far funzionare tutte queste cose, e anche ragionevolmente pulite, ma se vieni dal mondo sincrono (come lo ero io), è una curva di apprendimento significativa. (E non aiuta Microsoft a spingere gli eventi come il modo di gestire le chiamate WCF quando i callback, a mio parere, sono molto più puliti e meno suscettibili al genere di strani effetti collaterali di cui stavo parlando.)
(E sì, altre persone siano corrette nel dire che non è il linguaggio che è asincrona, quanto che i quadri particolari richiedono costruire il codice in modo asincrono -. Ma ottengo quello che vuoi dire)
Aggiornamento 2014.09.23 -
Ho lavorato molto di più con una varietà di framework asincroni da quando ho scritto la risposta sopra (come probabilmente tutti gli altri che hanno fatto qualsiasi codice web), e ho pensato di aggiungerne alcuni ulteriori note a caso:
Se stai usando un linguaggio come C# o F # che ha un supporto asincrono di prima classe, molto di questo diventa molto più semplice, almeno, una volta che ti giri nei bizzarri schemi async
/await
. Essere in grado di aggirarsi facilmente intorno a chiamate asincrone e avvolgere il tutto con un semplice try/catch
, è sorprendente se hai mai dovuto farlo alla vecchia maniera.
Se non si utilizza un linguaggio con il supporto asincrono di prima classe, iniziare a utilizzare qualunque promise
o future
o task
sostegno che il linguaggio non fornisce (ad esempio, JQuery di $.Deferred()
, o angolare di $q.defer()
. Quelli sono molto più pulito e fornisce una struttura migliore rispetto a quella che si ottiene normalmente con i callback
Il codice asincrono è fondamentale per la scrittura di sistemi scalabili lato server. Uno dei maggiori problemi con la realizzazione di una tipica scala di server Web è che inizia a esaurire i thread, almeno lo fa se dedica un thread per raggiungere la richiesta in arrivo. Se quel thread si blocca, perché è in attesa di un lungo eseguire la chiamata sincrona per finire, non è completamente disponibile per aiutare con qualsiasi altra cosa. Molto meglio è rendere il codice del tuo server web asincrono, in modo che quando stai aspettando una chiamata al DB per tornare, quel thread può andare a servire una mezza dozzina di altre richieste mentre il DB sta andando e facendo qualunque cosa sia il DB. A questo punto, per i sistemi altamente scalabili, async è l'unico gioco in città. (Basta chiedere a qualsiasi appassionato di Nodo.)
fonte
2009-12-18 19:49:47
Come può un linguaggio essere asincrono? –
@NSD: ciò che intende è che Flex non blocca mai: tutte le operazioni che potrebbero bloccare su altre piattaforme vengono implementate in modo asincrono. – Grokys
Hai una definizione per "linguaggio di esecuzione sincrono"? Oppure stai semplicemente interpretando la natura guidata da eventi di Flex (che si trova anche in quasi tutte le altre API della GUI, incluso Java) come "asincrona"? – kdgregory