этого делал не правильно. Что именно не правильно, пихал например в репозитории, куда-то в дата слой логику получение данных с каким-то делеем или же просто холодные флоу, получалось так, что например в репе есть какой-то флоу, мы его обновляем, его же по сути и обсервит кто захочет. Сейчас задумался, что не правильнее делать эт ов каких-то юзкейсах, например делаем юзкейс со StateFlow, в этом юзкейсе логика по получению данных из репозитория и обновление дежащего там стейта. Как кажется это как раз таки подходит под понятие бизнес логики, которая там и должна быть. При этом репозиторий отвечает только за то чтобы достать данные из сети или из бд. Но все равно мы должны, например, обсервить изменения в бд, и тогда уже по-любому нужен флоу в дата слое. Есть мысли какие на этот счет?
Такой подход с observable data активно продвигает гугл, вполне хорошо для решения некоторых задач. На первых этапах я не стал бы его бездумно применять вообще везде где можно, иногда всё-таки имеет смысл сделать какое-то одноразовое действие вместо того чтобы городить стейт. Но с другой стороны всякие Redux-ы это и есть один большой observable state, и постепенно мы движемся в этом направлении) Которое вроде классное, но нужно научиться его хорошо готовить на Андроиде. Если интересно, посмотрите гугловские сэмплы для Compose, у них там как раз стейт экрана собирается из нескольких StateFlow, которые идут из дата слоя.
Ну я думаю что подход с observable data уже давно используется, вопрос в том должно ли оно быть в дата слое, не должен ли он просто тупо заниматься тем чтобы отдавать то что у него попросили, а всем остальным уже заниматься в бизнес логике
Обсуждают сегодня