Комментарии 6
Вуаля! Так мы не только избавились от того громоздкого и неповоротливого ужаса, но и привнесли мощь RxJava в Presenter.
К сожалению, это ошибочное заблуждение.
Любое разбиение на слои так или иначе добавляет рутинный (boilerplate) код. Крайне часто интеракторы в данной концепции являются прокси между репозиторием и вью уровнями, тогда почему мы их не убирает для «сокращения кода»?
RxJava же по своей сущности является инструментом для планирования бизнес логики, а как следствие должна находиться на уровнях Repository & Interactor Implementation. Interactor Interface должен возвращать интерфейс который отвечает за возврат данных. А возвращая Observable в данной концепции вы теряете логику отвественности в слоях плюс использование Flowable Completable and etc. В чем главная проблема — если вы решите переехать на coroutines предположим, то Presentation layer тоже будет задет. С разделением через интерфейсы — вам будет необходимо изменить реализацию Interaction Impl. И вы сможете плавно выполнить миграцию.
Если вы хотите развлечения, то на уровне бизнес логики вам необходимы атомарные сущности интеракторов (чтение — запись в базу, запросы из веб апи и тд) каждый из которых может быть протестирован независимо, и композиционные сущности которые будут обьединять атомарные в бизнес логику. Да, данный подход будет еще более boilerplate но чистота кода (логическое разделение) обратно пропорциональна усложнению по сущностям.
В заключении — ваш подход весьма спорный и все зависит от обьема проекта, требований на тестирование и тд.
Добрый день, согласен с Вами, что «вынесение» Observable из Interactor-ов размывает слои и дает возможность Presenter-ам добавлять логику. Однако, как Вы и предложили, мы реализуем Interactor в ввиде небольшого use case, почти атомарной сущности. И тут конечно все зависит от проекта, и целей, которых мы хотим достичь. Если Вы предполагаете возможность в будущем переехать на другую технологию, на которой будет основываться реализация Inteactor-ов, то такой подход конечно не позволит вам это сделать. Если Вы планируете использовать RxJava в течение всей жизни проекта, что (могу ошибаться) часто бывает, то «вынесение» Observable позволяет нам проще сочетать различные Interactor-ы и использовать «удобный» набор операторов в Presenter внутри композиционных методов, например как в doAll() в статье. Однако, Ваше замечание является действительно очень важным, и я рад, что Вы подчеркнули эту особенность, которую я не отразил в своей статье.
Спасибо за статью! Читаю, и, как больше iOS разработчик, мысленно вижу, что если поменять Android на iOS, то суть в статье практически не изменится. И это круто! Важно при разработке многих продуктов, т.к. многие стараются выбирать одинаковые подходы для двух платформ.
Смотрели ли вы в сторону архитектуры Ribs?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как подружить RxJava с VIPER в Android, подходы применения и о структуре планировщиков