Comments 4
Однако эти недостатки компенсируются на больших экранах со сложной логикой. В таких архитектурах обязанности распределены лучше, чем в двунаправленных. Работа с кодом упрощается, так как легко отследить, откуда приходят данные, где они изменяются и куда передаются.
Расскажите, как вы поступаете в MVI в случаях, когда View должен запросить данные Model, обновить UI, еще запросить данные, еще обновить UI и т.д., т.е. вам нужно получить и отобразить данные в несколько последовательных шагов.
И еще насколько это будет проще по сравнению с двунаправленной архитектурой, где все шаги вы можете обозначить в одном методе?
Каждый раз когда надо обновить данные View запрашивает это у Intent, если нужно до обогатить данные, Intent делает это, если нет тогда сразу передает ивент в Model, тот в свою очередь обновляет данные для показа и View показывает
View —(событие)—> Intent —(до обогащенное данными событие)—> Model —(новое состояние)—> View
На каждом шаге, каждый раз необходимо проходить этот круг.
И еще насколько это будет проще по сравнению с двунаправленной архитектурой, где все шаги вы можете обозначить в одном методе?
В двунаправленных архитектурах все эти шаги можно обозначить одной функцией, в однонаправленных нужно делать круг. Как я писал выше это один из моментов критики таких архитектур
Интересно, что "двунаправленная архитектура" легко преобразуется в "однонаправленную". Достаточно в схеме "двунаправленной архитектуры" тот блок, что между двумя оставшимися находится, поделить на 2 части: одна часть пропускает сигналы в одну сторону, вторая – в противоположную. да, получится 4 блока, а не 3, но смысл тот же. И описанное преобразование гораздо проще, чем переписывать какой-нить MVVM на MVI. Ну, и плюшки все получаете от однонаправленности в том же MVVM.
Только тсссс!
По-моему можно проще:
[Removing the M from MVVM with SwiftUI](https://blog.stackademic.com/removing-the-m-from-mvvm-with-swiftui-a58b239e9e3e)
[The Dark Side of Unidirectional Architectures in Swift](https://medium.com/the-swift-cooperative/the-dark-side-of-unidirectional-architectures-in-swift-e4acf243ff1c)
А тут вообще красиво получается с декоратором
[Aspect-Oriented Programming in Swift](https://medium.com/the-swift-cooperative/aspect-oriented-programming-in-swift-f2366350c527)
А еще не понятно, как допустим таймер, который из REST данные вытаскивает делать.
В Clean это допустим UseCase, GetDataEvery10sUseCase и сразу понятно, где он должен быть и что делать.
Ну и вот можно подумать.
Цель
Mediator pattern: в первую очередь предназначен для управления сложными связями между несколькими объектами.
UseCase больше ориентирован на инкапсуляцию конкретного варианта использования или бизнес-логики.
Cвязи.
Mediator: объекты часто взаимодействуют двунаправленно через посредник.
UseCase обычно имеет однонаправленный поток (ViewModel -> [[UseCase]] -> Репозиторий).
Scope
Mediator: часто управляет набором связанных объектов.
UseCase ориентирован на одну операцию.
SwiftUI и MVI