Как разбить задачу в интеракторе

Есть репозитории

TreeRepository - получает список папок (вложенностей, дерево) ObjectsRepository - объекты (содержимое дерева) ObjectTypeRepository - описание типа объекта(ов)

1) Есть экран SplashView, в котором нужно все эти данные предварительно загрузить и закэшировать. 2) Есть экран ObjectsView в котором нужно собрать дерево используя данные из всех трех репозиториев.

Добавил интерактор ObjectsInteractor (пока просто как прокси работает, ну и объединяет данные из 3х репозиториев) и туда добавил получение джанныз из всех 3х репозиториев и получение комбинированных данных (т.е. собранное дерево с объектами). Этот интерактор имеет методы:

getTree()
getObjects()
getObjectTypes()
getObjectsInTree()

и он используется и в SplashView и в ObjectsView

Вопрос: Нужно делать разные интеракторы под эти 3 репозитория и объединять их где то в другом месте? Где?.. Сейчас, получается, нарушается SRP. А с другой стороны, кажется, что все нормально(одна бизнес фича, дерево объектов).. + подскажите источник, где хорошо(правильно) описано, что можно, а что нет по интерактору..


Ответы (1 шт):

Автор решения: Sergei Buvaka

На эту тему можно конечно создать целый холивар, т.к. тут нет понятия правильно. Но я это вижу так.

У вас есть 3 репозитория, каждый из них отвечает за подгрузку одних типов данных. Все круто SPR не нарушается. Дальше вы хотите эи данные объеденить. Тут есть 2 пути:

  • объеденять их всякий раз в месте где их получаете (где-то в Presentation слое) и получится дублирование кода.

  • второй вариант все же создать еще одну сущность которая будет ох объеденять и отдавать в Presentation слой уже готовые данные. Нарушается ли тут SPR? Думаю нет, сущность отвечает за одну конкретную фичу, она не знает о том как эти данные получаются. Пожалуй единственный нюанс может быть в том, что если к примеру вы в одном экране получаете все данные, а во втором вы используете только часть этих данных (например вам не нужен там запрос getTree(). Тогда все же лучше это генерить в месте получения.

Поэтому мой ответ ваш ObjectsInteractor вполне нормальное решение.

→ Ссылка