Как по Вашему правильно - Вайпер Модуль или Вайпер слой? возник спор, нужно больше мнений. Моя позиция - Вайпер модуль, а слой это составляющая модуля, вью слой, презентационный слой, слой бизнес логики и т.д. То есть модуль это более высокий уровень чем слой.
Я использую сервис ориентированную архитектуру, так вот в ней есть три слоя coreLayer -это винтики и шестеренки нашего приложения (менеджеры), выше уровнем - serviceLayer (сервисы), ещё выше - presentationLayer (вот в нем то и лежат модули)
Интересное видео, просты языком объяснил суть архитектурного решения 👍🏻 Мысли которые возникали при просмотре: 1. Также наряду с Initializer и Assembly часто используется Configurator 2. Возможно покажется вкусовщиной, но как по мне хороший вариант нейминга для протоколов - "\(ModuleName)\(LayerName)Output or Input", на примере View - LoginViewOutput и LoginViewInput. 3. Как вариант, можно в видео VIPER 2.0 (Кто здесь Бог нейминга?) можно затронуть тему ModuleInput и ModuleOutput, потому как после просмотра видео может возникнуть вопрос "Как "прокинуть" данный в следующий модуль?" и "Как же получить обратно данный из модуля?" В твоём примере это можно решить добавлением аргумента output: LoginModuleOutput? в метод createLoginModule, возвращаемым значением LoginModuleOutput у метода createLoginModule + dependency injection в теле самого метода. 4. "didTapLogin" - сразу видно что читал "The book of VIPER" от ребята из Rambler 😉👍🏻 Спасибо за видео, крутая идея с каналом 👨🏼💻👍🏻 Like + Share
Спасибо что не поленились столько текста написать! ) По поводу нейминга -да, есть смысл в этом. Чем проще что то искать в проекте тем правильнее подобраны названия классов и файлов, так что согласен со всем сказанным) На счет outputов модуля специально не затрагивал чтобы не усложнять, хотелось чтобы это было понятно хотя бы большенству, обязательно сниму практическое видео с примером того, как это работает в реальности и уже с общением между модулями! Про didTapLogin - верно подмечено 😉 За лайк и поддержку в виде share отдельное спасибо!
Это зоопарк из кода, сейчас попал на проект с этим вайпером просто в шоке сколько надо кода написать для создания 1 экрана, протаскивать логику очень сложно.Что займёт при обычном mvc 1 час на вайпере это x10 часов...
Все-таки, то, что убрали из использования UML плохо, верный был путь. Теперь, кто как ему нравится рисует, у всех свои нотации... Вообще, производство ПО, по-моему, приняло какой-то хаотический порядок. Наверное, это из-за того что возможности инструментов выросли и плюс суетливость бизнеса (рост потребления и тп) Хотя, вот недавно наткнулся на компанию, которые все-таки любят порядок и стандартизацию... Откуда вообще эта нотация взялась? ))) И вот мы видим на ролике полную неразбериху с нотацией по поводу стрелок;)
Минуточку. Кажется не раскрыта суть такого нагромождения. Я например не понял смысл презентера в данном примере. Ведь интерактор тоже может подготовить модель к нужному вью без презентера. Думаю тут есть более глубокая суть?
Отличный ролик получился, зачет, лайк то есть;) Прикольно что на бумаге и аккуратно. Эххх поторопился хвалить. Есть явное несоответствие ориентации стрелочек и названий протоколов))))))))))))
Видео отличное, но для того, кто вайпер не знает, запутается в стрелочках. А точнее, у кого какой протокол находится, и что вообще стрелочка означает? Если стрелочка - инжектирование, то та сущность, которая конформится к своему протоколу, просто инжектируется в ту сущность, в виде поля, к которой идет стрелочка. Но тогда названия протоколов совсем не понятны, и принцип по которым они называются. Что не хватает - просто указать у какой сущности какой протокол реализован, а дальше уже ясно, какие свойства с какими типами (тип протокола) есть у сущности. Стало бы яснее.
Привет! Понимаю, конечно, что видео может не набрать столько просмотров, сколько последние ролики на канале, но было бы очень круто увидеть реализацию VIPER в коде (особенно интересует ещё и фабрика модель данных -> вью модель)
Классное видео. Объяснил запутанное, простыми словами. Но мне кажется рисовать на листочке в 2020 году как то отстойно. Попробуй в след раз это делать в MIRO. Спасибо за видео!
Отличное видео!!! Лайк прожал! Но о чем оно я не понял)))), т.к. я не программист, решил пройти тест для программистов от нечего делать и там был вопрос что такое VIPER я пошёл гуглить и наткнулся на видео)) единственное что я понял, что эта хрень используется для создания приложений на iOS. )
Автору лайк, коллегам, которые городят этот write only огород без требований и намерений покрывать код тестами, лишь бы по модной архитектуре было, дизлайки.
Спасибо!) 1) не совсем так, вью принимает готовую вью модель, и задача вью разобрать поля модели в соответствующие UI элементы и заполнить их. То есть вью максимально пассивна. 2)дальше интерактора модели попадать не должны, презентер может запросить эти данные у интерактора (к примеру массив загруженных объектов) для того чтобы подготовить вью модель которую дальше прокинет во вью слой. Так как интерактор отвечает за бизнес логику то вполне нормально если он будет хранить актуальные данные к примеру тот же массив загруженных объектов, а презентер в случае необходимости обновить UI запрашивает их и формирует модель понятную вью.
@@itnadivane Спасибо за развёрнутый ответ! То есть, даже если интерфейс описывается программно, вью-контроллер не должен конфигурировать своё вью в методе viewDidLoad(), а должен реализовать методы для конфигурации вью, которые будет вызывать презентер, подписанный на протокол? Или я не правильно понял?
@@vladislavmerkulov1214 именно так! вью реализует метод протокола, через который с ней общается презентер и прокидывает в этот метод сконфигурированную вью модель. Протокольная связь в во многом помогает добиться хорошего покрытия тестами.
Как по Вашему правильно - Вайпер Модуль или Вайпер слой? возник спор, нужно больше мнений.
Моя позиция - Вайпер модуль, а слой это составляющая модуля, вью слой, презентационный слой, слой бизнес логики и т.д. То есть модуль это более высокий уровень чем слой.
Я использую сервис ориентированную архитектуру, так вот в ней есть три слоя coreLayer -это винтики и шестеренки нашего приложения (менеджеры), выше уровнем - serviceLayer (сервисы), ещё выше - presentationLayer (вот в нем то и лежат модули)
Здесь предельно ясно. То, как Вы написали, и логично, и понятнее.
Интересное видео, просты языком объяснил суть архитектурного решения 👍🏻
Мысли которые возникали при просмотре:
1. Также наряду с Initializer и Assembly часто используется Configurator
2. Возможно покажется вкусовщиной, но как по мне хороший вариант нейминга для протоколов - "\(ModuleName)\(LayerName)Output or Input", на примере View - LoginViewOutput и LoginViewInput.
3. Как вариант, можно в видео VIPER 2.0 (Кто здесь Бог нейминга?) можно затронуть тему ModuleInput и ModuleOutput, потому как после просмотра видео может возникнуть вопрос "Как "прокинуть" данный в следующий модуль?" и "Как же получить обратно данный из модуля?"
В твоём примере это можно решить добавлением аргумента output: LoginModuleOutput? в метод createLoginModule, возвращаемым значением LoginModuleOutput у метода createLoginModule + dependency injection в теле самого метода.
4. "didTapLogin" - сразу видно что читал "The book of VIPER" от ребята из Rambler 😉👍🏻
Спасибо за видео, крутая идея с каналом 👨🏼💻👍🏻 Like + Share
Спасибо что не поленились столько текста написать! ) По поводу нейминга -да, есть смысл в этом. Чем проще что то искать в проекте тем правильнее подобраны названия классов и файлов, так что согласен со всем сказанным)
На счет outputов модуля специально не затрагивал чтобы не усложнять, хотелось чтобы это было понятно хотя бы большенству, обязательно сниму практическое видео с примером того, как это работает в реальности и уже с общением между модулями!
Про didTapLogin - верно подмечено 😉
За лайк и поддержку в виде share отдельное спасибо!
Как хорошо в середине видео видно как вайпер жестко связывает всё подряд со всем подряд, прикрываясь протоколами)
А точнее?) В чем жёсткая связка ?
Оооо... класс!!! Это самое понятное объяснение!!! Пили исчо
Ждём видео на практике =))
Это зоопарк из кода, сейчас попал на проект с этим вайпером просто в шоке сколько надо кода написать для создания 1 экрана, протаскивать логику очень сложно.Что займёт при обычном mvc 1 час на вайпере это x10 часов...
давно не смотрел твои видяшки! Лайк и комент в продвижение канала! Спасибо за изложенный материал!!!
Спасибо большое за такой коммент!
Все-таки, то, что убрали из использования UML плохо, верный был путь. Теперь, кто как ему нравится рисует, у всех свои нотации... Вообще, производство ПО, по-моему, приняло какой-то хаотический порядок.
Наверное, это из-за того что возможности инструментов выросли и плюс суетливость бизнеса (рост потребления и тп)
Хотя, вот недавно наткнулся на компанию, которые все-таки любят порядок и стандартизацию...
Откуда вообще эта нотация взялась? )))
И вот мы видим на ролике полную неразбериху с нотацией по поводу стрелок;)
Красавчик!
Минуточку. Кажется не раскрыта суть такого нагромождения. Я например не понял смысл презентера в данном примере. Ведь интерактор тоже может подготовить модель к нужному вью без презентера. Думаю тут есть более глубокая суть?
Отличный ролик получился, зачет, лайк то есть;) Прикольно что на бумаге и аккуратно.
Эххх поторопился хвалить.
Есть явное несоответствие ориентации стрелочек и названий протоколов))))))))))))
...ээээ) а ну ка, никто до этого не заметил) подскажите где именно? если так то возможно я тоже пропустил
@@itnadivane сейчас попробую скомпоновать.. (с вас 10 баксов... шутка:))
Классно объяснил!Респект и уважуха)
Спасибо )
Отличное видео, все доступно и понятно, без воды
Спасибо!
Спасибо! ) приятно!
Видео отличное, но для того, кто вайпер не знает, запутается в стрелочках. А точнее, у кого какой протокол находится, и что вообще стрелочка означает?
Если стрелочка - инжектирование, то та сущность, которая конформится к своему протоколу, просто инжектируется в ту сущность, в виде поля, к которой идет стрелочка. Но тогда названия протоколов совсем не понятны, и принцип по которым они называются.
Что не хватает - просто указать у какой сущности какой протокол реализован, а дальше уже ясно, какие свойства с какими типами (тип протокола) есть у сущности. Стало бы яснее.
Лойс👍🏻
спасибо! Очень помог, намного стало понятнее
Очень круто все объяснил, я новичок, но уже какое то понимание есть. Спасибо, дружище! :)
Лайкосик
Спасибо)
Хорош, было интересно!
Спасибо)
super !👌💥
Когда будет второе видео (практика)?
Привет!
Понимаю, конечно, что видео может не набрать столько просмотров, сколько последние ролики на канале, но было бы очень круто увидеть реализацию VIPER в коде (особенно интересует ещё и фабрика модель данных -> вью модель)
Привет! да, тут нечего лукавить..технические видео это не массовый контент. Добавил в список роликов, в этом году выпущу )
Многие называют assembly роутером, т.е. роутер занимается сборкой. Это вообще имеет место быть?
Отличное видео
Можно ли использовать для backend например Golang, Django, PHP, NodeJS? применяется ли это в iOS?
Именно в iOS и применяется. Для бэка нет, тк там нет вью слоя и роутера.
@@barche75 Извини, но я ничего не понял)
Классное видео. Объяснил запутанное, простыми словами.
Но мне кажется рисовать на листочке в 2020 году как то отстойно.
Попробуй в след раз это делать в MIRO. Спасибо за видео!
Посмотрел что это, в след раз учту! Спасибо!
@@itnadivane классная штука) удачи 🍀
Отличное видео!!! Лайк прожал! Но о чем оно я не понял)))), т.к. я не программист, решил пройти тест для программистов от нечего делать и там был вопрос что такое VIPER я пошёл гуглить и наткнулся на видео)) единственное что я понял, что эта хрень используется для создания приложений на iOS. )
да, правильно)) Спасибо!
Автору лайк, коллегам, которые городят этот write only огород без требований и намерений покрывать код тестами, лишь бы по модной архитектуре было, дизлайки.
Привет! Отличное видео, но есть пара вопросов. 1) Вью сама себя конфигурирует/собирает? 2) Почему сырые модели идут дальше интерактора?
Спасибо!) 1) не совсем так, вью принимает готовую вью модель, и задача вью разобрать поля модели в соответствующие UI элементы и заполнить их. То есть вью максимально пассивна. 2)дальше интерактора модели попадать не должны, презентер может запросить эти данные у интерактора (к примеру массив загруженных объектов) для того чтобы подготовить вью модель которую дальше прокинет во вью слой. Так как интерактор отвечает за бизнес логику то вполне нормально если он будет хранить актуальные данные к примеру тот же массив загруженных объектов, а презентер в случае необходимости обновить UI запрашивает их и формирует модель понятную вью.
@@itnadivane Спасибо за развёрнутый ответ! То есть, даже если интерфейс описывается программно, вью-контроллер не должен конфигурировать своё вью в методе viewDidLoad(), а должен реализовать методы для конфигурации вью, которые будет вызывать презентер, подписанный на протокол? Или я не правильно понял?
@@vladislavmerkulov1214 именно так! вью реализует метод протокола, через который с ней общается презентер и прокидывает в этот метод сконфигурированную вью модель. Протокольная связь в во многом помогает добиться хорошего покрытия тестами.
Давай практику)))
Dmitry D да, обязательно сделаю ) через 1-2 видео)
@@itnadivane Когда будет практика?) С нетерпением жду
@@РомаВолков-я6н уже записал ) думаю на след неделе выйдет
@@itnadivane видимо никогда не выйдет...
@@РомаВолков-я6н снял) на след неделею смонтирую )
Давай по Flutter видосы!)
Здравствуйте. Нужен реальный пример на том же логине. Не совсем ясно, как это работает в котле.
да, скоро будет на канале) как это работает в реальной связке!
@@itnadivane когда будет доступно?))
так то уже за 100 лайков )) где видео с кодом ?))
Уже снято, нужно смонтировать)
@@itnadivane Таки ждем )) 😎
@@itnadivane когда будет видио?
Опять со звуком беда.
ну это одно из первых видео..поэтому был косяк