ну я в плане зачем новую сущность, если вроде бы у всех свои обязанности есть
Во-во, тоже самое видел в разборах-статьях. Потому удивился фразе "usecase > interactor"
А ок. Не правильно понял
Ну назвать можно как угодно, но технически они выполняют одни задачи
Ну вот же. Правда, читал про альтернативный подход именно на практике. Народ выделяет общие для флоу задачи (например логин флоу многослойный) в интерактор (класс на пяток методов), а потом дергают в нужном порядке в конкретных юзкейсах. Или вообще не без "юзкейсов", просто поставляется эдакий интерактор на Н-методов во ViewModel и там за них дергают. Мотивируют тем, что иначе слишком много бизнес-сущностей на каждый чих и читать не так удобно
А в интеракторе пару тройку репо?
Вангую, что да)
Интерактор так же зачастую может быть держателем нескольких юзкейсов, которые необходимы для реализации конкретной фичи Тогда Interactor > UseCase
Кстати, если отойти от озвученого выше, в чем проблема с парой разных репо в одном юзкейсе? Если нужно мапить данные из разных источников?
Не в чем в этом и смысл. Чтоб во вью модели небыло 5 репо а 1 кейс/интеракт
а, просто я прочел будто бы осуждение в прошлом сообщении об этом, потому было интересно)
Юзкейсы это домен слой, там не должно происходить никаких маппингов
Мне не понятна была прослойка интерактора перед юзкейсом.
Дык мапит репо
Окей, возводить еще репо, если нужно получить из двух репо данные и отобразить их "мердж"?
Окей, если ты о "склеивании" нескольких домен-моделек, которые вернула репа, то тогда само собой такое можно сделать в домен слое
Да, я именно об этом, это и называл маппингом
Обсуждают сегодня