Pull to refresh

Comments 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, то суть в статье практически не изменится. И это круто! Важно при разработке многих продуктов, т.к. многие стараются выбирать одинаковые подходы для двух платформ.
Добрый день! Спасибо за комментарий. Да, большинсво популяных архитектур для приложений с UI подходят и для обеих платформ, и для desktop разработки. Тут важнее всего, как мне кажется, удачно адаптировать и реализовать выбраннную архитектуру для целевой платформы.
Слышал о ней, но к сожалению, пока не было потребностей и возможности попробовать ее в проектах.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
auriga.com
Employees
501–1,000 employees
Registered