Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Еще бы с примерами… ммм…
Эм, а в чем суть статьи? Статей про MVP с примерами, как именно лучше все разделять и прочее тут тьма. Хотя, надо заметить, я не видел таких статей под iOS, но под android их реально много, поищи их, почитай.
> паттерн Clean architecture
Да не паттерн это, а подход к архитектуре с разделением кода на слои. У меня стойкое чувство, что последователи VIPER не утруждают себя просмотром лекции дяди Боба на эту тему (статья менее выразительна, на мой взгляд и хуже описывает основной посыл).
Да не паттерн это, а подход к архитектуре с разделением кода на слои. У меня стойкое чувство, что последователи VIPER не утруждают себя просмотром лекции дяди Боба на эту тему (статья менее выразительна, на мой взгляд и хуже описывает основной посыл).
Увы — VIPER не панацея, а скорее убийство в лоб, слишком радикально. Все таки VIPER хорош в теории, но путь к улучшению у вас близок к моему.
Мы в компании сейчас тестируем свой упрощеный «VIPER», хоть теперь это и не VIPER вовсе, но все принципы остались. В стандартной моедли (и в модели от Rambler) слишком много запутанностей, и теория разрушается той практикой, что написана в приложении-примере.
Но подход у нас примерно тот же —
1. VC это все таки view
2. Presenter — business layer, state machine
3. Interactor — core
4. Services & managers — разнорабочие
+ additionals: collection mediator — помогает вынести логику для коллекций, в которой приходится смешивать UI&business
Мы в компании сейчас тестируем свой упрощеный «VIPER», хоть теперь это и не VIPER вовсе, но все принципы остались. В стандартной моедли (и в модели от Rambler) слишком много запутанностей, и теория разрушается той практикой, что написана в приложении-примере.
Но подход у нас примерно тот же —
1. VC это все таки view
2. Presenter — business layer, state machine
3. Interactor — core
4. Services & managers — разнорабочие
+ additionals: collection mediator — помогает вынести логику для коллекций, в которой приходится смешивать UI&business
«Стандартная модель» VIPER — это статейка от Mutual Mobile с не очень хорошим примером, который хипстеры начали пытаться копировать, как священное писание. Рамблер попытался таки натянуть эту сову на глобус реальности, но это все тот же шаблонный подход (в буквальном смысле ибо есть генерируемые шаблоны классов).
Проблемы VIPER:
И это только вершина айсберга под названием VIPER.
Проблемы VIPER:
- во всех реализациях, что я видел, на каждый экран создается один presenter и один interactor. В случае достаточно сложного экрана получаем massive presenter и massive interactor (от чего вроде бы пытались уйти). Хотя Дядя Боб и Mutual Mobile говорили об interactor'е на отдельный юз кейс. Только недавно Рамблер начал понимать, что c этим нужно что-то делать.
- отсутствие состояния и единого источника истины (текущего состояния того что мы видим на экране). Дядя Боб описывал Clean Architecture на примере веб приложения типа тонкий клиент, там это нормально, но iOS приложения — толстые клиенты, поэтому нельзя слепо копировать этот подход.
- нечеткая ответственность presenter'а и interactor'а. Часто presenter просто пробрасывает вызовы между view и interactor не имея логики, что делает его избыточным.
- смешанная ответственность UIViewController, который помимо управления жизненным циклом своего view берет на себя обязанности рендеринга.
И это только вершина айсберга под названием VIPER.
В общем: я уверенно двигался от Model View Controller к Massive View Controller и с этим нужно было что-то делать.
Да, научиться писать код. Никто в здравом уме не парсит JSON в контроллере
Использую Clean Swift Architecture в нескольких проектах, результаты радуют. Единственное, что напрягает — это невозможность использовать какой-нибудь функционал (цикл View -> Interactor -> Presenter) в нескольких сценах. Как в VIPER с этим справляются? Часто же бывает, что два вью контроллера делают схожие вещи.
Выносить общую логику отдельных view в «подмодули», созданные специально для view. Solved!
И как в этом случае обеспечить цикл VIP?
Мы в таких случаях начали плодить базовые протоколы и классы и уже от них наследоваться. А что-то уходило и в категории.
Хотя бывало что переиспользовали и отдельные части, скажем, когда все в целом то же самое, вид выглядит по другому для какого-то одного частного случая.
Хотя бывало что переиспользовали и отдельные части, скажем, когда все в целом то же самое, вид выглядит по другому для какого-то одного частного случая.
как обычно. Не вижу тут проблем — общая логика view в подмолулях, логика зависящая от parent-моделя в нем. Плюс module input/output, Плюс сервисы со своими зонами ответственности — в общем проблем нет никаких
У меня была View: «любимый» сториборд, в котором было over9000 довольно много экранов, и который был похож на это
Это проблема не MVC или Storyboard как таковых, это проблема композиции и организации.
В нормальном проекте это было бы 5-8 разных сторибоардов и половина ViewController, которые вы видите должны быть разбиты на контейнеры. Тогда и проблема Massive VC уходит.
Да и вообще в более 50% случаев проблема MassiveVC — это проблема людей, которые пишут код, а не архитектурного подхода как такового.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Через MVP к VIPER. Часть первая: MVP