Progettazione di interfacce e asincroni

Question

Progettazione di interfacce e asincroni

#1 da (8 voti)

8

Supponiamo di aver creato l'interfaccia IFolderRepository con 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 DatabaseFolderRepository e diciamo CacheFolderRepositoryDecorator . Ora 'centinaia di righe dopo' Vorrei aggiungere funzionalità di cartelle SkyDrive quindi sono pronto ad aggiungere SkyDriveFolderRepository . Sfortunatamente mentre l'implementazione DatabaseFolderRepository utilizzava metodi sincroni per parlare con il database, skydrive uno usa un sacco di async e await . Cosa fare in questo caso? In caso di metodi void, contrassegnarlo come asincrono non è una soluzione (è necessario gestire le eccezioni). Devo cambiare interfaccia per restituire 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 tipi di ritorno Task (contro il quale non avrai bisogno della regola)?

c# async

posta fex 09.03.2014 - 13:26

fonte

1 risposta

Leggi altre domande sui tag c# async

Gestione degli errori nel sistema distribuito Programmazione reattiva vs pattern MVVM per la gestione degli aggiornamenti della GUI

score 8 · Accepted Answer

Probabilmente troverai questo articolo MSDN su Pratiche asincrone per essere una buona lettura.

Hai chiesto:

Unfortunately while DatabaseFolderRepository implementation used synchronous methods to talk with database, skydrive one uses a lot of async and await.

Questo è il punto in cui la sottosezione Async All the Way nell'articolo MSDN che ho collegato sarà pertinente alla tua situazione.

In particular, it’s usually a bad idea to block on async code by calling Task.Wait or Task.Result. This is an especially common problem for programmers who are “dipping their toes” into asynchronous programming, converting just a small part of their application and wrapping it in a synchronous API so the rest of the application is isolated from the changes. Unfortunately, they run into problems with deadlocks.

Poiché hai almeno un'interfaccia che deve essere asincrona, YAGNI è invertito. hai bisogno di apportare modifiche affinché le tue interfacce siano coerenti. Sì, creerà più sforzo per te. Ma il beneficio è meno rischioso di stallo; debugging meno complesso; e un blocco più prevedibile (quando deve effettivamente verificarsi).

Sto saltando alcune delle altre domande che hai chiesto, perché penso che ho affrontato il nocciolo della tua domanda. Affrontare il nucleo e il resto delle tue domande scompaiono. L'articolo è abbastanza coinvolto e affronta gli altri punti che hai sollevato, oltre a evidenziare ulteriori insidie.

La programmazione asincrona è una di quelle in cui devi abbracciare l'intero concetto e seguirlo. Cercando di "immergere le dita dei piedi" su base frammentaria, finisce per essere molto più complicato, quindi semplicemente saltando dritto dentro.