Conception d'interfaces et asynchrones

Supposons que j'ai créé une interface IFolderRepositoryavec des méthodes comme celle-ci:

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

et j'ai implémenté DatabaseFolderRepositoryet disons CacheFolderRepositoryDecorator. Maintenant, «des centaines de lignes plus tard», j'aimerais ajouter la fonctionnalité des dossiers SkyDrive, donc je suis prêt à ajouter SkyDriveFolderRepository. Malheureusement, alors que l' DatabaseFolderRepositoryimplémentation utilisait des méthodes synchrones pour parler avec la base de données, skydrive one utilise beaucoup de asyncet await. Que faire dans un tel cas? En cas de méthodes vides, le marquer comme async n'est pas une solution (nécessité de gérer les exceptions). Dois-je changer d'interface pour revenir Task<T>? Bien sûr, cela fonctionnera dans l'exemple ci-dessus, mais ce ne sont que 2 classes d'implémentation d'interface. Ou la plupart de mes interfaces devraient-elles avoir des Tasktypes de retour (par contre, vous n'en aurez pas besoin)?

c# async

— fex
source

Sans rapport avec votre question (désolé), mais si vous avez une IFolderinterface, pourquoi comptez-vous sur une implémentation concrète ( Folder) dans toutes vos méthodes?

— Konrad Morawski

Qu'attend votre interlocuteur? L'API que vous implémentez est-elle basée sur des codes d'erreur, des exceptions, des rappels ou quoi? Pouvez-vous le changer?

— david.pfx

@KonradMorawski c'était une faute de frappe - désolé. Il est basé sur des exceptions et je ne peux pas le changer.

— fex

Vous trouverez probablement cet article MSDN sur les pratiques asynchrones pour une bonne lecture.

Tu as demandé:

Malheureusement, alors que l' DatabaseFolderRepositoryimplémentation utilisait des méthodes synchrones pour parler avec la base de données, skydrive one utilise beaucoup de asyncet await.

C'est là que la sous-section Async All the Wayde l'article MSDN que j'ai lié sera pertinente pour votre situation.

En particulier, c'est généralement une mauvaise idée de bloquer le code asynchrone en appelant Task.Wait ou Task.Result. Il s'agit d'un problème particulièrement courant pour les programmeurs qui «plongent leurs orteils» dans la programmation asynchrone, convertissant juste une petite partie de leur application et l'encapsulant dans une API synchrone afin que le reste de l'application soit isolé des changements. Malheureusement, ils rencontrent des problèmes de blocages.

Puisque vous avez au moins une interface qui doit être asynchrone, YAGNI est inversé. Vous êtes va devoir faire des changements afin que vos interfaces sont cohérentes. Oui, cela créera plus d'efforts à l'avance pour vous. Mais l'avantage est moins de risque d'impasse; débogage moins complexe; et un blocage plus prévisible (quand il doit réellement se produire).

Je saute quelques-unes des autres questions que vous avez posées, car je pense avoir répondu au cœur de votre question. Traitez le cœur et le reste de vos questions disparaît. L'article est assez impliqué et aborde les autres points que vous avez soulevés ainsi que les pièges supplémentaires.

La programmation asynchrone est l'une de celles où vous devez embrasser tout le concept et simplement y aller. Essayer de simplement «tremper vos orteils» au coup par coup finit par être beaucoup plus compliqué que de sauter directement.