NoFearJoe Feb 11 2017 at 19:05

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

3 min

14K

System Analysis and Design*Development for iOS*Development of mobile applications*Designing and refactoring*

+10

Comments 13

s_suhanov Feb 13 2017 at 14:14

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

NoFearJoe Feb 13 2017 at 16:37

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

serg_p Feb 13 2017 at 14:48

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

tapoton Feb 13 2017 at 16:38

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

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

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

PavelGatilov Sep 1 2017 at 10:07

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

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

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

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

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

Или же

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

RomanVolkov Feb 13 2017 at 16:38

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

syouth Feb 13 2017 at 17:41

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

NoFearJoe Feb 13 2017 at 17:43

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

syouth Feb 14 2017 at 14:10

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

IbrahimKZ Feb 14 2017 at 11:13

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

NoFearJoe Feb 14 2017 at 14:20

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

ned19 Feb 14 2017 at 14:14

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

Statusgman Sep 1 2017 at 10:07

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

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

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

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

Show the best of all time