MVP с интерактором и репозиторием + rxjava 2. Куда звонить Наблюдать и подписываться - PullRequest
Новая
       30

MVP с интерактором и репозиторием + rxjava 2. Куда звонить Наблюдать и подписываться

0 голосов
/ 25 января 2019

У меня есть Android-приложение на основе MVP + интеракторы + репозитории. Все слои от репозитория до докладчика подключены с использованием реактивных потоков (RxJava 2). Просматривать запросы чего-либо от докладчика, докладчик запрашивает у интерактора, интерактор запрашивает из репозитория, а репозиторий запрашивает у самого API. Ответ проходит через те же слои, что и реактивный поток от API до докладчика. Каждый слой может отображать данные для нижележащего слоя.

Вопрос в том. Где я должен вызывать subscribeOn (io () / computation () / etc) и наблюдаем (AndroidSchedulers.mainThread ())? Я думаю, что наблюдаю (AndroidSchedulers.mainThread ()) следует вызывать из докладчика, потому что в интеракторе могут выполняться тяжелые вычисления. Во многих примерах метод subscribeOn (io () / computation () / etc) вызывается из докладчика, но я не согласен с таким подходом. Я думаю, что докладчик не должен решать, в какой поток загружать данные. Репозиторий должен решить, в какой поток загружать данные из API. Например, если у нас есть интерфейс хранилища для загрузки контактов. Реализация может получать данные из БД или Интернета или в памяти. Нет необходимости создавать поток для хранилища в памяти. Таким образом, хранилище должно решить, подписываться на планировщик io / computation / etc или нет.

Есть идеи?

1 Ответ

0 голосов
/ 25 января 2019

Я бы не назвал subscribeOn() и observeOn() на уровне хранилища по следующим причинам:

  • Методы, которые неявно выполняются в разных потоках, очень сложны в использовании и могут вызвать проблемы вклиенты, которые их вызывают.
  • Если вы хотите составить несколько потоков из разных репозиториев, было бы удобнее иметь контроль над ними.Если они подписаны на разные потоки, это может привести к незначительным ошибкам, снижению оптимальной производительности и затруднению чтения кода.
  • Это добавляет еще одну ответственность на уровень репо.Вместо того, чтобы быть простыми хранилищами данных, репозитории теперь знают о потоках.На мой взгляд, это нарушает принцип единственной ответственности.

Я обычно называю subscribeOn() и observeOn() на последнем слое перед представлениями - в этом случае это будет ваш уровень презентатора.Там у меня есть полный контроль над составом интеракторов и лучшее суждение о том, где я хочу обрабатывать вещи и где мне нужны результаты обработки.

...