Почти все посмотрел, вставлю свои пять копеек. Сразу оговорюсь, что

Question

Почти все посмотрел, вставлю свои пять копеек. Сразу оговорюсь, что

у меня не клиенты для облачного сервиса, а IoT-устройства, которые должны уметь в офлайн, роботу с серверным менеджмент-софтом и имеют свой веб-интерфейс, так что presentation-слой у меня делится на UI (MVP) и web (REST API).

Я пошел подобным путем как в докладе, только общение между фичами (модулями?) я решил на уровне интеракторов. У меня интеракторы делятся грубо говоря на два типа - менеджеры(глобальные, не имеют своего сопутсвующего представления, реализовывают интерфейс SingletonInteractor, имеют конкретную ответсвенность, e.g. NetworkManager, СallManager, SipManager, SoundManager, NotificationManager, LogManager) и интеракторы, которые используются в слое представлении(обычно имеет свой скоуп на уровне di). И по большему счету задача вторых сводится в агрегировании первых, чтобы получить доступ к нужным частям системы.

Т.е, разбирая пример с баннерами, у меня был бы AdRepo, AdManager, AdScreenInteractor, где AdScreenInteractor не имел бы своего репозитория, но выступал агрегатором/фасадом/делегатом в примитивном случае, или делал определенные манипуляции с другими менеджерами, например, насчитал виртуальную валюту за просмотр рекламы через AppCoinManager. И в случае BannerScreenInteractor, он бы инкапсулировал AdManager, DraftManager, WeatherManager. В большинстве своем Manager-ы занимаются делегированием к репозиториям, а так же делают Rx-обертки, но иногда и выполняют какие-то фоновые бизнес-задачи (например, перерегистрация на сервере телефонии, если она отвалилась больше 30 секунд) .

Инжектить в один инерактор несколько репозиториев неплохо себя показывало, когда они с одним датасорсом работали, например, репы под капотом с Room работают, и самое геморное - это M:N связь организовать. Но в кейсах, когда по дефолту одно поведение, а в зависимости от пользовательских конфигов, другое/третье, то проще эту логику инкапсулировать в одном месте.

#it #programming #russian #software

0

11.02.2019

1 ответов

4 просмотра

Кирилл Романенко · Accepted Answer

Вот кстати про интеракторы-менеджеры и интеракторы-представления: жиза, точно то же самое. Только у меня вот какая связь: интерактор даёт указание репозиторию, который инкапсулирует в себе информацию, с каким именно менеджером он общается, а тот выбирает нужного менеджера. Ну и пока что так выходит, что у меня на каждый экран есть презентер, интерактор и гейтвей. Идея тут в том, чтобы максимально разграничить ответственность и "зону досягаемости". Т.е., например, презентер на экране добавления пользователя знает только те методы интерактора, которые помогут ему добавить пользователя, а больше ему и не нужно.

214 похожих чатов

Почти все посмотрел, вставлю свои пять копеек. Сразу оговорюсь, что

1 ответов

Похожие вопросы