Comments 6
Опытный разработчик сам построит необходимую архитектуру под проект, а новичок наплодит лишние сущности, пытаясь применить новое. Так кому нужен очередной шаблон?
+3
Поддержу вас. Настолько сложные архитектурные решения, как VIPER и его производные, требуют уже определенной квалификации, чтобы проект не превратился в нечто громоздкое и неповоротливое, где львиная доля времени разработчика уходит не на функционал, а на следование архитектуре. Имхо, VIPER можно применять только тем, кто уже чувствует в себе силы и, главное, понимает, зачем он это делает.
0
Аналогичных такому паттерну шаблонов можно наклепать огромное количество. Обычный переMVC и недоVIPER. Главное при внедрении любого паттерна, четко понимать полномочия отдельных классов и для чего они нужны.
Для большего упрощения можно вообще сделать два класса: PatternViewController и PatternLogic.
Для большего упрощения можно вообще сделать два класса: PatternViewController и PatternLogic.
0
Вот как мы в Альфа-банке заимплементили CleanSwift.
github.com/alfa-laboratory/YARCH
github.com/alfa-laboratory/YARCH
0
ИМХО, это не до VIPER. Циклическое однонаправленный поток данных решает одну задачу, помогает разработчику менять единственное место истинной информации о стейте. Но порождает кучу других не удобств:
— Если нужно поменять какое-то незначительное состояние, ты должен юзать весь цикл и затронуть все элементы слоя, вместо того чтобы просто оповестить об этом ViewModelInput.
— Чаще всего у разработчика порождается некая сущность, что не вписывается в эту модель и он изобретает вызов сервисов прямиком из нажатия кнопок. Минуя всю карусель.
— Отдельная тема воркеры, в VIPER реюзабл логика это четкое понятие Services доступ к которому имеет Interactor и ни кто другой. В YARCH от Альфы, мы видим как и презентер и интерактор обращаются к воркерам.
— и т.д.
В итоге мы изобретаем MVC обмазанный воркерами, где с высоты VIPER видно, что малыш подрастает и будет великим RVIPER`ом, пока что единственной архитектурой для долгосрочных проектов!
— Если нужно поменять какое-то незначительное состояние, ты должен юзать весь цикл и затронуть все элементы слоя, вместо того чтобы просто оповестить об этом ViewModelInput.
— Чаще всего у разработчика порождается некая сущность, что не вписывается в эту модель и он изобретает вызов сервисов прямиком из нажатия кнопок. Минуя всю карусель.
— Отдельная тема воркеры, в VIPER реюзабл логика это четкое понятие Services доступ к которому имеет Interactor и ни кто другой. В YARCH от Альфы, мы видим как и презентер и интерактор обращаются к воркерам.
— и т.д.
В итоге мы изобретаем MVC обмазанный воркерами, где с высоты VIPER видно, что малыш подрастает и будет великим RVIPER`ом, пока что единственной архитектурой для долгосрочных проектов!
0
Sign up to leave a comment.
Clean swift архитектура как альтернатива VIPER