DD
Ну это ведь и получается чистое проксирование, слой созданный только для того чтобы отдать из data в ui
Size: a a a
2021 June 27
DD
Без логики, для которой он создан
JF
пустое проксирование это плохо, потому что классов становится больше, а проблемы остаются те же
А viewModel нет разницы у кого запрашивать данные, у Interactor или у RepositoryInterface
А viewModel нет разницы у кого запрашивать данные, у Interactor или у RepositoryInterface
IS
ну я еще раз говорю, представлению нафиг не надо знать что там за репы и как ими пользоваться)
DD
Оно ими пользуется точно также как и интеракторами, в случае если репо - просто прокси
JF
да что же такое. Он и не будет этого знать
IS
будет слишком много логики не нужной во вьюмодели
DD
Какая представлению разница о чем он в этом случае знает
JF
вообще ничего не поменяется
DD
Какой логики? Из того что было сказано выше - логики там не было
JF
просто заменить тип класса
UsersInteractor на UsersProvider
UsersInteractor на UsersProvider
JF
судя по всему там и сигнатуры останутся
IS
ну и будет то же самое по сути
JF
да. И интерактор не нужен
IS
классы могут называться и не interactor, главное суть же
JF
так в Вашем интеракторе нет сути
IS
какие-то интереракторы могут быть не сильно полезны, там будет один вызов репозитория и все, но это не всегда бывает так
JF
При всем уважении к Вам. По формулировке "ну в моем понимании круто когда domain..." видно, что Вы не разобрались кто и что делает
JF
мы говорим про проксированный интерактор - он не нужен. Если в нем есть банальная логика фильтрации - то он нужен
IS
ну я и говорю, что бывают разные ситуации. Но в случае с проксирвоанием обычным тоже приходится это делать, потмоу что я выстраивают зависимости как presentation --> domain <-- data