ЕК
Size: a a a
2021 June 15
2021 June 16
FL
Тут скорее вопрос в том, стоит ли view(его viewmodel) в которой происходит редактирование, знать о бд:)
Y
В целом нет, view model должна знать только о доменном слое.
AN
Да можно и ссылку на бд указать вместо условного репозитория. Только если потребуется поменять что-то в бд - придется пол прилаги переделывать
s
А о репозитории?
I
мы сейчас о Clean говорим?
s
Допустим
Y
смотря где находится репозиторий
вопрос более широкий на самом деле, в простом приложении можно принебречь чем-то, в большом такого делать нельзя
в идеале конечно нужно чтобы view model общалась только с интеракторами
вопрос более широкий на самом деле, в простом приложении можно принебречь чем-то, в большом такого делать нельзя
в идеале конечно нужно чтобы view model общалась только с интеракторами
Y
Нет универсального рецепта архитектуры для любого приложения. Можно конечно что-то подобное сделать но часто это будет большой оверхед.
Нужно просто понимать для чего и зачем ты что-то разделяешь по слоям и как будешь этим пользоваться.
Нужно просто понимать для чего и зачем ты что-то разделяешь по слоям и как будешь этим пользоваться.
T
Если из репозиторя возвращается Result<SomeObject>, то как с ним работать в интеракторе? В result есть колбеки onSucess. Onerror. Или будет лучше не оборачивать так?
Y
как это в Result могут быть колбэки? куда они колбэчат? Или интерактор может на них подписаться?
T
Не колбеки, а просто объекты возвращают(someobject или throwable)
Y
в общем случае нормально, если тот кто слушает это, должен как-то реагировать на ошибочное состояние
JF
можно спокойно передавать репозиторий в vm
JF
а как у Вас интерактор должен с ними работать? просто в Presentation передавать?
T
Делать какие то операции над данными и передавать в vm
JF
ну вот пусть делает "какие-то операции и возвращает"
T
Вопрос в том как обрабатывать корректно состояния onError и onResult в интеракторе
JF
если передать абстракцию репозитория в ViewModel не нарушаются правила клина
JF
соответственно логике