бизнес логика должна решать, откуда сейчас должны прийти данные - из сети или БД.
Обычно менеджер внутри репозитория смотрит на актуальность кеша и по определённой логике решает, нужно ли достать данные из сети или кэша, или вообще из памяти.
Но есть другой случай. Например, в репозитории есть метод получения информации о пользователе. Все компоненты получают эту информацию, запрашивая репозиторий, который сам всё разруливает.
Но бывают случаи (например, пользователь только что отправил запрос на изменение логина), когда мы не можем просто запросить у репозитория информацию о пользователе (вдруг он вернёт закешированную?). В таком случае, класс бизнес логики указывает репозиторию, что ему нужны обязательно свежие данные, что-то типа флага needFreshData, и репозиторий (точнее менеджер) понимает, что сейчас нужно именно сделать запрос на сервер.
И тут остаётся маленький вопрос нэйминга, что needFreshData, или что-нибудь такое, звучит как бизнес требование, тогда как getDataFromServer уже лезет в реализацию.
вопрос исключительно когерентности данных в приложении, разруливается состояниями/правильным кэшированием
Обсуждают сегодня