@atimca24 апр 2017 в 15:52

UIKit + Viper или MVC здорового человека

3 мин

8.7K

Комментарии 9

@rsi 24 апр 2017 в 17:23

У вас вышела некая школьная/упрощенная версия Вайпера. В целом архитектура не плохая и ее можно использовать при этом не прикладывая много усилий в борьбе с uikit. Но это не вайпер, так как основаная идея вайпера это соблюдение принципов solid. А в вашей версии они все нарушены, слишком многого ответственностей на каждом из компонентов. Увеличена связность, тестировать сложнее. Но думаю для мелких проектов и проектов где на первом месте скорость разработки, оно зайдёт.

@atimca 24 апр 2017 в 17:43

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

@rsi 25 апр 2017 в 01:28

Еле коротко то вы все нарушили. Начнем с роутера, это компонент отвечающий за переход от одного модуля к другому, UINavigationController отвечает за все что угодного кроме этого, фактически это контейнер для контроллеров, он не знает куда надо переходить дальше. UIViewController опять же не разделим с View он управляет анимацией, навигацией и даже просто внешним видом. Он фактически весь состоит из того чего в нем быть не должно. С interactor`ом и view у вас особых проблем нет, так как они остались из изначального вайпера. Почитайте про solid, поймете что ваша архитектура не про него. Попробуйте покрыть модуль тестами и снова поймете что у вас проблемы. Ваша архитектура это скорее MVC от эапла как она должна быть + interactor. Это лучше чем просто massive view controller, но не более.

@atimca 25 апр 2017 в 06:05

Было бы прекрасно, если бы вы дали пример, где можно увидеть более правильное построение вайпера. Так-как я видел только достаточно костыльные реализации

@rsi 25 апр 2017 в 06:19

Можно в шаблонах для generamba посмотреть
например
https://github.com/rambler-digital-solutions/generamba-catalog/tree/master/swifty_viper

@atimca 25 апр 2017 в 07:25

Спасибо! В данном примере получилось тоже самое, только вид с боку. По сути весь модуль держит вью, что на мой взгляд не есть хорошо. Так-же презентер просто ждет сигнала от вью в методе viewIsReady, в своей статье я сделал на этом акцент, что все то-же самое можно сделать, если прентер и будет viewcontroller'ом. Но вот никак не раскрыто, что делать с navigationController и ему подобными.

@rsi 25 апр 2017 в 07:30

Я вам объяснил что это не то же самое, в презентере нет ничего лишнего, он ничего не знает о view, его легко тестировать, его легко понять, у него всего одна ответственность. То что модуль в памяти держит View это издержки архитектуру apple, и пусть это не лучший вариант, он равно намного лучше чем делать презенте из VC.

@DnV 24 апр 2017 в 18:52

«MVC здорового человека» — звучит вызывающе. А я бы назвал статью «Как придумать себе проблемы». Если лыжи не едут, то логично их смазывать, а не приделывать к ним педали.

@Krizai 1 мая 2017 в 19:46

Один из бенефитов вайпера, это упрощение тестирования компонентов за счет соблюдения solid ( как уже было скзаано выше). Как вы предполагаете тестировать ваши компоненты, если бОльшая их часть завязана на UIKit?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий