Я usecase делаю "плоскими", без асинхронщины. Такие классы много легче

Question

Я usecase делаю "плоскими", без асинхронщины. Такие классы много легче

писать по TDD, да и просто покрывать тестами. Интерактор - это по факту фасад над usecase, который берет на себя асинхронщину. Это его единственная ответственность.

Репозиторий - это гейт между бэком, локальным хранилищем и ядром (domain). UseCase обращается к repository, не задумываясь о том, откуда/куда брать/отдавать данные. Соответственно в слое domain у тебя интерфейс репозитория. Реализация репозитория - в слое репозиториев.

Репозиторий разруливает потоки данных. Если нет данных, обращается к интерфейсу remote storage. Если нужно кэшировать, сохраняет полученные с бэка в локальное хранилище (через интерфейсы локальных хранилищ). Если данные уже есть в локальном хранилище, берет их оттуда через интерфейсы локальных хранилищ. Соответственно в слое репозиториев нужно знать интерфейсы локальных и удаленных хранилищ. А вот их реализации создаются в слоях local и remote.

Что это дает? Если к примеру решили перейти на другую БД, переписывание модуля local не затронет модули remote и repository. Соответственно компилятору нет нужды перекомпилировать остальные модули.

#it #programming #russian #software

0

16.09.2020

1 ответов

20 просмотров

Анатолий Петров · Accepted Answer

Спасибо за подробный ответ, очень доходчиво! С репозиторием я всегда так делал. А вот с usecase и interact не до конца понимаю.. interact оборачивает usecase с элементом асинхронности? А interact может содержать несколько usecase? К примеру, получение данных из репозитория, нужно сперва посмотреть их в кэше, потом в базе, потом запросить их по http. Можете на этом примере пояснить, как это будет с intecart и usecase?

214 похожих чатов

Я usecase делаю "плоскими", без асинхронщины. Такие классы много легче

1 ответов

Похожие вопросы