Проектування інтерфейсів та асинхронізація

Припустимо, я створив інтерфейс IFolderRepositoryз такими методами:

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

і я реалізував DatabaseFolderRepositoryі дозволяю сказати CacheFolderRepositoryDecorator. Тепер "сотні рядків пізніше" я хотів би додати функціональність папок SkyDrive, тому я готовий додати SkyDriveFolderRepository. На жаль, поки DatabaseFolderRepositoryреалізація використовувала синхронні методи для розмови з базою даних, у програмі skydrive використовується багато asyncі await. Що робити у такому випадку? У разі недійсних методів, що позначають його асинхронізацією, не є рішенням (необхідність обробки обставин). Чи потрібно змінити інтерфейс, щоб повернутися Task<T>? Впевнений, що він буде працювати у наведеному вище прикладі, але це лише два класи впровадження інтерфейсу. Або у більшості моїх інтерфейсів є Taskтипи повернення (проти цього вам не потрібно це правило)?

c# async

— фекс
джерело

Не пов’язане з вашим запитанням (вибачте), але якщо у вас є IFolderінтерфейс, чому ви покладаєтесь на конкретну реалізацію ( Folder) у всіх своїх методах?

— Конрад Моравський

Що очікує ваш абонент? Чи API, який ви реалізуєте, базується на кодах помилок, винятках, зворотних викликах чи що? Чи можете ви це змінити?

— david.pfx

@KonradMorawski це була помилка друку - вибачте. Він заснований на винятках, і я не можу його змінити.

— фекс

Напевно, ви знайдете цю статтю MSDN про асинхронні практики добре прочитаною.

Ти запитав:

На жаль, поки DatabaseFolderRepositoryреалізація використовувала синхронні методи для розмови з базою даних, у програмі skydrive використовується багато asyncі await.

Ось де підрозділ статті Async All the WayMSDN, до якого я пов’язаний, буде відповідати вашій ситуації.

Зокрема, зазвичай погана ідея блокувати код асинхронізації, викликавши Task.Wait або Task.Result. Це особливо поширена проблема для програмістів, які "занурюють пальці ніг" в асинхронне програмування, перетворюють лише невелику частину свого додатка і загортають його в синхронний API, так що решта програми ізолюється від змін. На жаль, вони стикаються з проблемами із тупиками.

Оскільки у вас є принаймні один інтерфейс, який повинен бути асинхронним, YAGNI змінюється на зворотному рівні. Ви це збирається необхідно внести зміни , щоб ваші інтерфейси сумісні. Так, це створить більше зусиль для вас. Але користь - менший ризик тупикової ситуації; менш складна налагодження; і більш передбачуване блокування (коли воно насправді має відбутися).

Я пропускаю деякі інші запитання, які ви задали, як я думаю, що я вирішив основу вашого питання. Попрацюйте з ядром, а решта ваших запитань відпадають. У статті досить причетна стаття, яка стосується інших питань, які ви порушили, а також вказує на додаткові підводні камені.

Асинхронне програмування - це одне з тих, де вам потрібно прийняти всю концепцію і просто піти з нею. Спроба просто "занурити пальці ніг" на шматках закінчується набагато складніше, ніж просто стрибати прямо.