В
Я к тому что если у меня 4 экрана в памяти где нужен конкретный интерактор , не создавать же его каждый раз как новый обьект )
Size: a a a
2020 April 26
МE
С чего бы это нельзя?
Потому что flow должен быть presentation-domain-data-domain-presentation, а не циклы flow в domain
AO
Потому что flow должен быть presentation-domain-data-domain-presentation, а не циклы flow в domain
И как вызов другого интерактора нарушает этот принцип?
AO
да и CLEAN немного о другом
АЕ
Вот из одного интерактора дёргать другой точно нельзя. Почему это не может быть один интерактор "UserInteractor"? Он и в сеть сходит и в БД запишет
Не вижу ни одной причины почему нельзя. Как логику-то без этого композировать.
sm
Если есть фича юзеры и есть фича оплата, в интерактор оплаты передается интерактор юзера, то в случае если фича юзеры чутка изменится, то это изменение может зааффектить фичу оплаты, а она этого и не ждала.
Да и бизнлогика работы с юзерами у фичи юзеры (в юзео интеракторе), врядли будет совпадать с той логикой что нужна фиче оплата.
Да и бизнлогика работы с юзерами у фичи юзеры (в юзео интеракторе), врядли будет совпадать с той логикой что нужна фиче оплата.
sm
Передавать один интерактор в другой можно - только осторожно, ну или если еще любите риск, и коленок не жалко.
В
как же тогда соединить логику оплаты и обновления юзера?
В
Если без риска
sm
Репозиторий юзера и репозиторий оплаты передавать в интерактор оплаты.
В
ммм , спасибо , как вариант )
МE
как же тогда соединить логику оплаты и обновления юзера?
В презентере наверное
В
В презентере наверное
В презентере обращаться сначала к интерактору юзера, потом к интерактору оплат чтобы сделать оплату и потом чтобы сохранить юзера в БД снова обращение к интерактору юзера? )
МE
В презентере обращаться сначала к интерактору юзера, потом к интерактору оплат чтобы сделать оплату и потом чтобы сохранить юзера в БД снова обращение к интерактору юзера? )
Мне кажется, что так и нужно. Ты забрал поля пользователя, сделал какой-то запрос по оплате, результаты в презентере получил и сохранил опять же через интерактор оплат.
AO
Мне кажется, что так и нужно. Ты забрал поля пользователя, сделал какой-то запрос по оплате, результаты в презентере получил и сохранил опять же через интерактор оплат.
мдээ, презентер у нас теперь занимается бизнес-логикой
МE
В презентере обращаться сначала к интерактору юзера, потом к интерактору оплат чтобы сделать оплату и потом чтобы сохранить юзера в БД снова обращение к интерактору юзера? )
Если я не прав, то подскажи как это все прокидыаать между тремя слоями верно
В
Мне кажется, что так и нужно. Ты забрал поля пользователя, сделал какой-то запрос по оплате, результаты в презентере получил и сохранил опять же через интерактор оплат.
Вот сейчас если я все это в презентер у себя добавлю - не представляю как потом это читать . А если такого рода логика будет на многих экранах......
AO
Так уже сказали что нет проблемы общения между интеракторами, ты сам выдумал себе ограничение про флоу
В
Оверкода выходит оч много
МE
Вот сейчас если я все это в презентер у себя добавлю - не представляю как потом это читать . А если такого рода логика будет на многих экранах......
Ну я наверно дал маху. Верно сказали про презентер и бизнес логику