EK
Возможно я не прав, но опять же имхо, use case больше отображает суть)
Size: a a a
2020 April 26
EK
В одной статье пишут что юскейс и интерактор это одно и тоже, в другой - разные вещи
Use case это случай бизнес логики, смена почты как пример. Он может быть вызван с любой необходимой тебе вью модели
АЕ
Use case это термин из описания требований к приложению. В коде называйте его как хотите)
EK
Use case это термин из описания требований к приложению. В коде называйте его как хотите)
Аминь) Но согласись, это вносит небольшую путаницу, как сейчас)
EK
Смысл архитектуры от части - это понимание друг друга, потому что мы следуем общим концепциям
EK
А тут проблема из-за нейминга
В
Сейчас я из ВМ обращаюсь напрямую к репозиториям и в конечном счете это привело меня к некоторым архитектурным трудностям , таким как описал выше. Когда на одном экране я получаю инфу по юзеру из одного репозитория, а на другом экране у меня происходят события которые меняют юзера и его нужно обновить , а сделать это можно в другом репозитории
В
И вот пытаюсь понять логику создания юскейс/интерактора и чем они отличаются вообще
АЕ
Всем привет. Начал копать в clean architecture и не могу понять как именно формировать логику интерактора. Допустим у меня есть экран с информацией о пользователе (Экран А ) и есть экран где я могу у пользователя сменить какие-то данные, предположим Имейл (экран Б ) и после этого обновить данные о пользователе и записать в БД. Для экрана А есть вьюмодель и для нее нужен свой интерактор с доступом к репозиториям и для экрана Б так же нужен интерактор , который будет иметь доступ к тому же репозиторию с методами пользователея и в этом интеракторе Б я буду еще и обновлять пользователя ?Спасибо
Попробуйте немного забыть про экраны, и подумать, что именно вы делаете. Вы редактируете и просматриваете информацию о пользователе. Напрашивается сущность, которая за это отвечает, назовем ее интерактором. Сделайте в ней нужные методы, в потом вызывайте из нужных вьюмоделей. Всё)
EK
Сейчас я из ВМ обращаюсь напрямую к репозиториям и в конечном счете это привело меня к некоторым архитектурным трудностям , таким как описал выше. Когда на одном экране я получаю инфу по юзеру из одного репозитория, а на другом экране у меня происходят события которые меняют юзера и его нужно обновить , а сделать это можно в другом репозитории
А почему работа с профилем разделена на разные репозитории?
В
Извините , описал не так. На одном экране гружу информацию по юзеру. На другом экране произвожу оплату услуги, которая есть у юзера и потом возвращаюсь опять на главную , где должен быть уже обновленный узер
В
UserRepository и ServicePaymantRepository
В
И вот у меня есть user screen и ServicePaymantScreen
В
До этой проблемы я не парился и на каждом экране просто каждый раз с сервера загружал новые данные о юзера при открытии
АЕ
Проблема всё еще не очень понятна
В
Задача такая, Каждый раз , когда на каком-то экране я меняю информацию о юзере - я должен сразу обновить юзера с сервера и записать в БД
В
Чтобы в БД была всегда актуальная информация
АЕ
Обновляет и записывает юзера UserInteractor, например у него есть метод refresh. Этот метод может вызвать любой другой интерактор когда нужно. Подходит?
В
Да, вполне, спасибо.Я просто немного не понимаю какой логикой руководствоваться при создании интерактора
В
Для каждого экрана свой интерактор , или для каждого логического сценария один интерактор