Комментарии 4
Было бы здорово описать минусы тех. решений о которых вы говорите "дебри". Возможно у тех решений есть плюсы, которых нет у вас. И на долгой дистанции(или большого проекта) ваше решение не будет работать.
Лично для меня пока из существующих решений для среднего проекта мне подошёл MvRx от AirBnb.
Во-первых они построили его на существующих элементах(Fragment, ViewModel). Во-вторых всю работу со Store/Reducer скрыли с глаз долой.
Store монолит. нельзя отдельно протестировать actor, reducer.
К стору также нужно обязательно аттачить view, что также сказывается на тестировании. Нельзя к нему приаттачить TestObservable какой нибудь и протестировать смену стейтов.
В результате теряется главный плюс MVi, слабосвязанность и хорошая тестируемость отдельных компонентов.
Store без View вне тестирования не имеет смысла. Делать Store наследником ObservableSource, к которому можно подписаться, я не считаю правильным, т.к. не нравится идея работы с подпиской из View (или, что хуже, дополнительной прослойки).
О тестировании в целом. Тестирование того же Reducer все же возможно, но не обособленно. И TestObservable приаттачить можно, но, как и в случае с Reducer, придется приложить дополнительные усилия в виде различных оберток.
Что мне не нравилось (и из-за чего возникали сложности с данными решениями):
1) Отход от стандартных терминов (вообще, здесь сложно говорить о каких-то стандартных терминах в MVI), навязывая свои. Не критично, но вызывает своего рода сложности;
2) Раздутость. Некоторые под каждый кусок функционала используют отдельный класс. SRP — это здорово, не спорю. Изначально делал также, но мне не понравилось, как выглядело конечное решение; по итогу — многое заинлайнил.
3) Подписка / .subscribe() / Disposable внутри View.
Основной минус получившегося решения (с чем согласен с linyaKoder) — потеря хорошей тестируемости, предполагаемой подходом. Вырос он из того, что на этапе «сейчас» об этом пункте я попросту не подумал. Постараюсь исправить это в дальнейшем.
Приручая MVI