Progettazione di interfacce e asincrono

Supponiamo di aver creato un'interfaccia IFolderRepositorycon metodi del genere:

IEnumerable<Folder> GetAllFolders();
Folder GetFolderWithId(int id);
void AddFolder(Folder newFolder);
void ModifyFolder(Folder folderToModify, Folder folderAfterModification);
void RemoveFolder(Folder folderToRemove);

e ho implementato DatabaseFolderRepositorye diciamo CacheFolderRepositoryDecorator. Ora "centinaia di righe dopo" vorrei aggiungere la funzionalità delle cartelle SkyDrive, quindi sono pronto per aggiungere SkyDriveFolderRepository. Sfortunatamente mentre l' DatabaseFolderRepositoryimplementazione utilizzava metodi sincroni per parlare con il database, skydrive uno usa molto asynce await. Cosa fare in tal caso? In caso di metodi nulli che lo contrassegnano come asincrono non è una soluzione (è necessario gestire l'eccezione). Devo cambiare interfaccia per tornare Task<T>? Sicuramente funzionerà nell'esempio sopra ma sono solo 2 classi di implementazione dell'interfaccia. O la maggior parte delle mie interfacce dovrebbe avere Tasktipi di ritorno (contro di te non ne avrai bisogno)?

c# async

— fex
fonte

Non correlato alla tua domanda (scusa), ma se hai IFolderun'interfaccia, perché fai affidamento su un'implementazione concreta ( Folder) in tutti i tuoi metodi?

— Konrad Morawski,

Cosa si aspetta il tuo chiamante? L'API implementata si basa su codici di errore, eccezioni, callback o cosa? Puoi cambiarlo?

— david.pfx

@KonradMorawski è stato un errore di battitura - scusa. Si basa su eccezioni e non posso cambiarlo.

— fex

Probabilmente troverai questo articolo MSDN sulle pratiche asincrone per essere una buona lettura.

Hai chiesto:

Sfortunatamente mentre l' DatabaseFolderRepositoryimplementazione utilizzava metodi sincroni per parlare con il database, skydrive uno usa molto asynce await.

È qui che la sottosezione Async All the Waynell'articolo MSDN che ho collegato sarà pertinente alla tua situazione.

In particolare, è generalmente una cattiva idea bloccare il codice asincrono chiamando Task.Wait o Task.Result. Questo è un problema particolarmente comune per i programmatori che stanno "immergendo le dita dei piedi" nella programmazione asincrona, convertendo solo una piccola parte della loro applicazione e avvolgendola in un'API sincrona in modo che il resto dell'applicazione sia isolato dalle modifiche. Sfortunatamente, si verificano problemi con deadlock.

Dato che hai almeno un'interfaccia che deve essere asincrona, YAGNI è invertito. Ti sei andando necessità di apportare modifiche in modo che le interfacce siano coerenti. Sì, creerà più impegno per te. Ma il vantaggio è meno rischio di deadlock; debug meno complesso; e blocco più prevedibile (quando effettivamente deve verificarsi).

Sto saltando alcune delle altre domande che mi hai posto mentre penso di aver affrontato il nocciolo della tua domanda. Affronta il nucleo e il resto delle tue domande scompare. L'articolo è abbastanza coinvolto e affronta gli altri punti che hai sollevato, oltre a sottolineare ulteriori insidie.

La programmazione asincrona è una di quelle in cui devi abbracciare l'intero concetto e seguirlo. Cercare di "immergere le dita dei piedi" su base frammentaria finisce per essere molto più complicato di un semplice salto.