У них классный слой есть. JPA. Ой больно мне это нравтся.. У них такие худые контроллеры. Есть сервисы.(У нас тоже как бы контроллер можно сказать Активити. это тупо клей с вию и логикой. Логика можно сказать это презентер(У сприенгеров это Сервис слой). А дальше Дао классы (Это Spring Data мощнааая штука нравится мне это, думаю написать такую же для андроида) и дальше ОРМ(Хайбернет) и управление с энтити.

Всем привет. Подскажите, как вы решаете такую проблему:
Есть интерактор. У него торчат Observable. Если пихнуть в onError ошибку, которую необходимо показать на ui, то придётся пересоздавать Observable. Как такой проблемы избежать?
Я пока что придумал лишь держать в базовом интеракторе отдельный Observable для ошибок и в базовом презентере подписываться и переопределять метод их обработки в дочерних презентерах.

Мне кажется немного по-другому, в спринг МВС spring controller - это больше  презентер, чем вью, а спринг сервис - тот же интерактор. с репозиторием попроще, он только в базу бегает, в проектах побольше есть dal слой, который решает в какую базу побежит репозиторий, но я только с трехслойными работал.

Мне кажется немного по-другому, в спринг МВС spring controller - это больше  презентер, чем вью, а спринг сервис - тот же интерактор. с репозиторием попроще, он только в базу бегает, в проектах побольше есть dal слой, который решает в какую базу побежит репозиторий, но я только с трехслойными работал.

Вообще у меня такое подозрение, что данное поведение должно разоуливаться в Интеракторе.
Но не видя код и задачу, тяжело сказать

Даа не)) Сервис это не интерактор) Интерактор по сути Юзкейс Кординатор. И это пер юз кейс. А Сервис у них большой

Вся бизнес логика в сервисе, потому и большой) кстати, в спринге есть правило - на один сервис один репозиторий, то есть если сервису нужен еще один репозиторий, то он дергаеи другой сервис, с интерактором такой проблемы не поднималось?

Наконец-то подоспел ответ =)

 1. Бизнес-логика и модели данных. Знаете, я соглашусь с тем, что Бизнес-логика не должна ничего знать о моделях данных Даты-уровня и UI-уровня. Эти знания ей ни к чему. Плюс да, во всех источниках бизнес-логика представляется максимально изолированной от всех слоев. А тут я ее наоборот загружаю лишними данными и серьезно завязываю на конкретные модели. Поэтому Репозиторий должен предоставлять Интерактору уже готовые бизнес-модели, а Интерактор выдает ui уже обновленные, но тоже свои бизнес-модели, UI при необходимости мапит их.
 2. Место Репозитория. Я бы не стал относить Репозиторий чисто к бизнес-логике. Но это это и не Дата-уровень. По мне, Репозиторий - это надстройка над Датой, с которой непосредственно взаимодействует бизнес-логика. Именно Репозиторий решает, откуда брать данные и как.
 3. Обязанности Репозитория + вопросы кеширования. С осознанием того, что Бизнес-логика ничего не знает о моделях Даты, и что она получает уже готовые бизнес-модели от Репозитория, роль Репозитория несколько меняется. Теперь это не просто проводник запросов в сеть или БД. Теперь Репозиторий отвечает за маппинг данных, выбор источников данных, а также за кеширование. Интерактору выдается просто готовые модели. Раньше у меня Интерактор знал о моделях Даты и мог сам принимать решения, как кешировать. Но это не верно и не очень красиво.
Есть возражения, что если осуществлять еще и кеширование, то как-то много всего будет в Репозитории. Ну тут остается только посоветовать - делегируйте во вспомогательные классы. У Фернандо показан хороший пример делегирования через Фабрику и DataStore (в статье http://hannesdorfmann.com/android/evolution-of-the-repository-pattern, раздел Evolution of the Repository Pattern term). Там фабрика решает, какой DataStore задействовать для конкретного id.
Если для принятия решения о кешировании нужна информация с другого Репозитория, то пускай Интерактор передаст через аргумент метода нужную инфу в Репозиторий. Вообщем тут Интерактор отвечает за взаимодействием и необходимый обмен информацией между Репозиториями. Например у одного репозитория запросил, какой режим сейчас (пользовательский или демо), а в другой репозиторий передал эти данные для получения корректного списка операций.
modeRepository.getMode()
   .flatMap(mode -> operationsRepository.getOperations(mode))
 4. Исходя из вышесказанного Репозиторий должен тестироваться.
 5. Если вам нужно сделать приложение быстро, можно, конечно, не заморачиваться с маппингом, а передавать модель, полученную с запроса. Но если приложение чуть более серьезное и долгое, то лучше маппить. Так как по своему опыту, по Дате-уровне или по логике получения данных всегда что-то может поменяться. Бизнес-логика про это вообще не должна знать.
 6. Про проектирование. У меня в докладе показано проектирование снизу вверх. Но почитав источники Александра соглашусь, что проектирование сверху-вниз намного более привлекательней, да и позволяет быстро получить результат.


Один бы я не дошел до этого. Вот что значит коллективный разум! Еще раз спасибо Александру за отличный вопрос и очень развернутое свое мнение. Заставил меня несколько переосмыслить некоторые вещи.

Ну то есть разруливается в интеракторе и приходит в презентер уже враппером?

Так точно)

И у дао все клево. Дергаешь виртуальный метод который не сушествует) И прям в методе описываешь что нужно))

Дао и репозиторий - это одно и тоже в спринге

Вся бизнес логика в сервисе, потому и большой) кстати, в спринге есть правило - на один сервис один репозиторий, то есть если сервису нужен еще один репозиторий, то он дергаеи другой сервис, с интерактором такой проблемы не поднималось?

Может я ошибаюсь. Но как я знаю нет. ДАО это именно что бы не писать запросы ручками. Оно предоставляет запросы на JPA слой