Progettazione del componente asincrono

Penso che osservabile sia il modello corretto.

Promise / Task / Future / Deferred con async / await è più adatto quando si ha un singolo evento (o una catena logica ramificata di eventi) da seguire. Avrai bisogno di molto lavoro aggiuntivo per adattarlo alla tua situazione.

La maggior parte delle implementazioni utilizza un generatore * / IEnumerable / iterator sotto le copertine comunque, con await che diventa yield new Promise / yield return new Task e la codifica di chiamata che viene convertita in un enumeratore di promesse / attività.

Rx / osservabile è più adatto quando gli eventi possono sparare ripetutamente e vuoi trattarli come una raccolta ripetuta nel tempo.

Potresti eseguire il rollover della tua classe per gestirlo (probabilmente usando async / await ) ma dovrai risolvere molti degli stessi problemi che Rx ha già senza risparmiare su alcuna complessità.

La tua soluzione potrebbe essere troppo complessa perché sta facendo troppo dentro di sé. Se, ad esempio, si suddivide la gestione di attività a esecuzione prolungata (processo AKA) nel proprio componente, è possibile limitare l'interazione alla gestione di tali attività. Allo stesso modo, il componente di gestione eventi ad hoc potrebbe dover utilizzare il gestore lavoro, ma limitare i test a quegli eventi può renderlo un po 'più facile da gestire. Ho seguito personalmente questo approccio con un paio di progetti.

Il modo in cui gestisci il test è di un paio di interfacce ben scelte. L'implementazione può essere il tuo osservabile reattivo, o un'implementazione personalizzata, a seconda delle tue vere esigenze. L'interfaccia IJob potrebbe essere simile a questa:

public interface IJob
{
    string Id { get; }
    bool IsRunning { get; }
    Task Handle { get; }
    void Cancel();
    // and anything else you need.
}

Puoi anche creare una versione tipizzata per gestire attività che restituiscono un valore.

La linea di fondo è che potresti aver bisogno solo di uno dei componenti di gestione delle attività a lungo termine nel tuo sistema. Puoi testare facilmente tutte le interazioni con questo componente, e puoi testare il componente stesso abbastanza facilmente. Poiché la proprietà Handle espone un Task puoi facilmente avere il codice che sarà semplicemente await il lavoro da completare.

Non ho lavorato con Reactive Observables, ma puoi fornire un handle Task collegato a un risultato semplice abbastanza facilmente usando un TaskCompletionSource . All'interno del lavoro è possibile impostare il risultato o lo stato di errore quando è necessario esplicitamente, e il codice esterno non è il più saggio. Il TaskCompletsionSource ha una proprietà Task che può essere utilizzata per Handle sopra.

Puoi avere tanti componenti "ad hoc" di cui hai bisogno e, a patto che abbiano un modo coerente di gestire i lavori lunghi, dovrebbe semplificare la progettazione in qualcosa che tutti possano capire.