Комментарии 13
Вот знаете, не могу с вами не согласиться. По сути, просто нужно понимать где VIPER будет хорош, а где нет. Поэтому, в принципе, можно считать что оба поста: за VIPER и против — дополняют друг друга. :)
0
Размышления, описание- проблем есть. Ни примеров — ни выводов?????
+1
Не могу не согласиться с автором.
Только чувствую, как сейчас понабегут с криками, что автор адепт секты.
Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.
Только чувствую, как сейчас понабегут с криками, что автор адепт секты.
Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.
0
Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое».
Это может привести к застою и слепому фанатизму. Я считаю, что нужно уметь слушать обе стороны и собирать как можно большее количество информации. Вопрос только в том как эту информацию обрабатывать и как воспринимать факты. А так же в каких ситуациях плюсы архитектуры вам помогают, а в каких ситуациях минусы сильно сыграют вам не на руку. Опять таки, не читая критику, очень сложно будет осознать недостатки и минуса того или иного подхода.
Например то как я воспринимаю факт из этой статьи:
Высокий порог вхождения — неопытные программисты не смогут с ней работать
— Ага, понятно, у меня в команде 2 джуна и 2 мидла, значит скорее всего потратим много времени на тренинг джунов под новую архитектуру, а сроки проекта даже при стандартных подходах поставлены впритык — значит отметаем.
Или же
— Ага, нас тут 3 синьора и мы уже все давно поняли — значит можно пробывать или же писать дальше.
0
Мне иногда кажется, что VIPER придумали ради холиваров. Я пока не видел другого такого архитектурного паттерна, про который везде спорят. Везде.
+2
«Во-первых, Presenter хранит состояние всего модуля»
А для чего тогда модель(ну или энтити, как она называется в вайпер)?
А для чего тогда модель(ну или энтити, как она называется в вайпер)?
0
Модель хранит данные. Состояние, если говорить просто, определяет что можно сделать с этими данными в текущий момент
+1
Вы используете классический VIPER или немного модифицированную версию от Рамблера? Или между ними нет существенной разницы?
0
Я использую версию от Рамблер, но с незначительными изменениями, которые мы решили сделать в компании.
Между этими версиями есть разница — о ней писали в Рамблере. В основном, в компаниях видоизменяют архитектуру исходя из собственных взглядов и требований(например, в uber используют Riblets). В этом нет ничего плохого, так как основная задача — следовать принципам чистой архитектуры.
Между этими версиями есть разница — о ней писали в Рамблере. В основном, в компаниях видоизменяют архитектуру исходя из собственных взглядов и требований(например, в uber используют Riblets). В этом нет ничего плохого, так как основная задача — следовать принципам чистой архитектуры.
0
Сам когда-то думал что VIPER это громоздко, ненужно и вообще просто «модно». После применения этой архитектуры в нескольких проектах я поменял своё мнение :)
+1
Немного занудства:
Это же нарушает принцип Single Responsibility. Столько обязанностей у одной сущности.
Но на самом деле это неизбежно, должен же быть класс, который никак не переиспользовать при изменении требований.
Вопрос к знатокам VIPER:
Недавно делал одну функциональность для проекта на VIPER. Компонент представлял собой UITableView c двумя секциями с возможностью перетаскивания ячеек.
Для удобства разместил алгоритм перетаскивания в UITableViewDelegate непосредственно в слое View. Это допустимо или следовало бы прокидывать вызовы делегата до интерактора и обратно во View?
Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения
Это же нарушает принцип Single Responsibility. Столько обязанностей у одной сущности.
Но на самом деле это неизбежно, должен же быть класс, который никак не переиспользовать при изменении требований.
Вопрос к знатокам VIPER:
Недавно делал одну функциональность для проекта на VIPER. Компонент представлял собой UITableView c двумя секциями с возможностью перетаскивания ячеек.
Для удобства разместил алгоритм перетаскивания в UITableViewDelegate непосредственно в слое View. Это допустимо или следовало бы прокидывать вызовы делегата до интерактора и обратно во View?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему VIPER это хороший выбор для вашего следующего приложения