Comments 9
У вас вышела некая школьная/упрощенная версия Вайпера. В целом архитектура не плохая и ее можно использовать при этом не прикладывая много усилий в борьбе с uikit. Но это не вайпер, так как основаная идея вайпера это соблюдение принципов solid. А в вашей версии они все нарушены, слишком многого ответственностей на каждом из компонентов. Увеличена связность, тестировать сложнее. Но думаю для мелких проектов и проектов где на первом месте скорость разработки, оно зайдёт.
Спасибо за комментарий! Если вам не сложно, опишите пожалуйста подробно, где я что нарушил? Все-таки эта статья была больше написана для того, чтобы разобраться самому почему так делать не стоит и как правильно
Еле коротко то вы все нарушили. Начнем с роутера, это компонент отвечающий за переход от одного модуля к другому, UINavigationController отвечает за все что угодного кроме этого, фактически это контейнер для контроллеров, он не знает куда надо переходить дальше. UIViewController опять же не разделим с View он управляет анимацией, навигацией и даже просто внешним видом. Он фактически весь состоит из того чего в нем быть не должно. С interactor`ом и view у вас особых проблем нет, так как они остались из изначального вайпера. Почитайте про solid, поймете что ваша архитектура не про него. Попробуйте покрыть модуль тестами и снова поймете что у вас проблемы. Ваша архитектура это скорее MVC от эапла как она должна быть + interactor. Это лучше чем просто massive view controller, но не более.
Было бы прекрасно, если бы вы дали пример, где можно увидеть более правильное построение вайпера. Так-как я видел только достаточно костыльные реализации
Можно в шаблонах для generamba посмотреть
например
https://github.com/rambler-digital-solutions/generamba-catalog/tree/master/swifty_viper
например
https://github.com/rambler-digital-solutions/generamba-catalog/tree/master/swifty_viper
Спасибо! В данном примере получилось тоже самое, только вид с боку. По сути весь модуль держит вью, что на мой взгляд не есть хорошо. Так-же презентер просто ждет сигнала от вью в методе viewIsReady, в своей статье я сделал на этом акцент, что все то-же самое можно сделать, если прентер и будет viewcontroller'ом. Но вот никак не раскрыто, что делать с navigationController и ему подобными.
Я вам объяснил что это не то же самое, в презентере нет ничего лишнего, он ничего не знает о view, его легко тестировать, его легко понять, у него всего одна ответственность. То что модуль в памяти держит View это издержки архитектуру apple, и пусть это не лучший вариант, он равно намного лучше чем делать презенте из VC.
«MVC здорового человека» — звучит вызывающе. А я бы назвал статью «Как придумать себе проблемы». Если лыжи не едут, то логично их смазывать, а не приделывать к ним педали.
Один из бенефитов вайпера, это упрощение тестирования компонентов за счет соблюдения solid ( как уже было скзаано выше). Как вы предполагаете тестировать ваши компоненты, если бОльшая их часть завязана на UIKit?
Sign up to leave a comment.
UIKit + Viper или MVC здорового человека