Scrittura di un nuovo codice in async, ma chiamando la sincronizzazione

Question

Scrittura di un nuovo codice in async, ma chiamando la sincronizzazione

#1 da (3 voti)
#2 da (0 voti)
#3 da (-1 voti)

3

Sto scrivendo un nuovo codice e vorrei scriverlo usando async e attendere, ma il codice chiamante al momento non supporta async. È giusto scrivere il nuovo codice in async e chiamarlo sync finché il codice chiamante non supporta async?

O dovrei scrivere il codice di sincronizzazione e poi convertirlo in un secondo momento? E sarebbe considerato un debito tecnico?

public Result Execute( Paramerters parameters ) {
    return ExecuteAsync( parameters ).Result;
}

public Task<Result> ExecuteAsync( Paramerters parameters ) {
    ...
}

Execute si trova su un'interfaccia e viene chiamato da un altro codice che non è ancora asincrono. È corretto creare la versione asincrona e chiamarla da Execute finché il codice che chiama Execute viene convertito in async? Il mio vecchio codice è scritto in .net 4.5.1 ma non è ancora stato convertito in async.

c# technical-debt .net asynchronous-programming

posta Jake Rote 04.03.2016 - 13:46

fonte

3 risposte

Leggi altre domande sui tag c# technical-debt .net asynchronous-programming

C'è qualche valore nell'usare una libreria Promises contro le Promesse ES6? Raccolta calcolata troppo?

score 3 · Answer 1

Se si desidera chiamare il codice asincrono in modo sincrono, è necessario gestire la sincronizzazione. L'unica idea che ho è che si bloccherebbe il thread chiamante fino al termine dell'operazione asincrona. Lo considero estremamente pericoloso, perché potrebbe portare a deadlock. Soprattutto se si sta lavorando nell'interfaccia utente, in cui è pianificata l'esecuzione delle attività sul thread dell'interfaccia utente e si bloccherebbe il thread esatto. Esempio qui: Non bloccare il codice asincrono

Quindi sto scrivendo il codice sincrono finché non sarai in grado di cambiare il chiamante in versione asincrona.

score 0 · Answer 2

Perché vuoi rendere il codice asincrono? Se è perché il design richiede il supporto per le chiamate asincrone, scrivilo usando async / await . Se non è necessario che il codice sia asincrono, non farlo. Se i requisiti cambiano in seguito e richiedono la refactoring del codice, allora non è un debito tecnico, si sta semplicemente adattando ai mutevoli requisiti. OTOH, se lo si scrive come asincrono e si incorre in overhead per chiamarlo in modo sincrono, allora quello è cattivo design. Allo stesso modo, rendere il codice più difficile da debugare e ragionare senza motivo è anche una cattiva progettazione. Quindi, a meno che non sia chiaro che il tuo percorso in avanti è asincrono, tienilo sincronizzato.

score -1 · Answer 3

In ogni caso c'è un debito tecnico, ma dobbiamo fare per alleggerire il meglio. meglio cambiare immediatamente in asincrono e attendere

Il tuo codice sarà somme cosa ike questo:

public Result Execute(string parameters)
{
    Task<Result> task = Task.Run<Result>(async () => await ExecuteAsync());
    return task.Result;
}

public async Task<Result> ExecuteAsync(string parameters)
{
    Task<Result> result = SomeOtherOperationAsync();
    // more code here...
    return await result;
}

Spero che aiuti