Почему VIPER это хороший выбор для вашего следующего приложения

[@s_suhanov]

Вот знаете, не могу с вами не согласиться. По сути, просто нужно понимать где VIPER будет хорош, а где нет. Поэтому, в принципе, можно считать что оба поста: за VIPER и против — дополняют друг друга. :)

[@NoFearJoe]

Я просто хотел восстановить равновесие)

[@serg_p]

Размышления, описание- проблем есть. Ни примеров — ни выводов?????

[@tapoton]

Не могу не согласиться с автором.

Только чувствую, как сейчас понабегут с криками, что автор адепт секты.

Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.

[@PavelGatilov]

Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое».

Это может привести к застою и слепому фанатизму. Я считаю, что нужно уметь слушать обе стороны и собирать как можно большее количество информации. Вопрос только в том как эту информацию обрабатывать и как воспринимать факты. А так же в каких ситуациях плюсы архитектуры вам помогают, а в каких ситуациях минусы сильно сыграют вам не на руку. Опять таки, не читая критику, очень сложно будет осознать недостатки и минуса того или иного подхода.

Например то как я воспринимаю факт из этой статьи:

Высокий порог вхождения — неопытные программисты не смогут с ней работать

— Ага, понятно, у меня в команде 2 джуна и 2 мидла, значит скорее всего потратим много времени на тренинг джунов под новую архитектуру, а сроки проекта даже при стандартных подходах поставлены впритык — значит отметаем.

Или же

— Ага, нас тут 3 синьора и мы уже все давно поняли — значит можно пробывать или же писать дальше.

[@RomanVolkov]

Мне иногда кажется, что VIPER придумали ради холиваров. Я пока не видел другого такого архитектурного паттерна, про который везде спорят. Везде.

[@syouth]

«Во-первых, Presenter хранит состояние всего модуля»
А для чего тогда модель(ну или энтити, как она называется в вайпер)?

[@NoFearJoe]

Модель хранит данные. Состояние, если говорить просто, определяет что можно сделать с этими данными в текущий момент

[@syouth]

Ну ок.
А при сериализации(ну например нужно сделать сейв) вы это состояние из пресентера куда сбрасываете?
Просто то, что вы описали — это не состояние а скорее логика смены состояний. Само состояние как раз таки хранится(ну по крайней мере должно) в модели.

[@IbrahimKZ]

Вы используете классический VIPER или немного модифицированную версию от Рамблера? Или между ними нет существенной разницы?

[@NoFearJoe]

Я использую версию от Рамблер, но с незначительными изменениями, которые мы решили сделать в компании.
Между этими версиями есть разница — о ней писали в Рамблере. В основном, в компаниях видоизменяют архитектуру исходя из собственных взглядов и требований(например, в uber используют Riblets). В этом нет ничего плохого, так как основная задача — следовать принципам чистой архитектуры.

[@ned19]

Сам когда-то думал что VIPER это громоздко, ненужно и вообще просто «модно». После применения этой архитектуры в нескольких проектах я поменял своё мнение :)

[@Statusgman]

Немного занудства:

Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения

Это же нарушает принцип Single Responsibility. Столько обязанностей у одной сущности.
Но на самом деле это неизбежно, должен же быть класс, который никак не переиспользовать при изменении требований.

Вопрос к знатокам VIPER:
Недавно делал одну функциональность для проекта на VIPER. Компонент представлял собой UITableView c двумя секциями с возможностью перетаскивания ячеек.
Для удобства разместил алгоритм перетаскивания в UITableViewDelegate непосредственно в слое View. Это допустимо или следовало бы прокидывать вызовы делегата до интерактора и обратно во View?