Блин чувак, ты очень крут, я всю голову сломал над тем как прикрутить классический mvc к интерфейсу пользователя, очень помог! Как говорится, Майк потел и нам велел
Контент супер, подача огонь! Давно пытаюсь разобраться с разнообразными технологиями построения графических приложений( winforms, wpf ...) и прилогающимся к ним паттернам. Автор нашёл компромис демонстрируя данные технологии на примерах работы с движком unity причём в таком изложение, что становится понятно как всё это перенести на вышеперечисленные десктопные инструменты разработки. Так можно и всё ООП по полочкам разложить😊 что очень актуально, учитывая как мно литературы в наше время и сколько времени нужно тратить чтобы докопаться до истины (не все могут себе это позволить работая по совсем другому профилю). Автору огромное спасибо за материал! Он однозначно годный, т.к преподносится не только структура и правила пользования данным шаблоном, но и рассуждения о причинах перехода к данной технологии, а также суть самой идеи, что соответственно заставляет голову думать, а не просто зазубривать очередной шаблон как аксиому, не развивая объектное мышление что является нормой для начинающих джунов в наши дни. Мне как начинающему джуну остается надеятся что будет больше подобного контента и что автор на гитхабе будет выкладывать проекты не только на unity, но и реализации на других технологиях разработки типа winforms и wpf, всё таки на таких исходниках потыкать былобы куда проще 😅 но это пожелание 😊 а вы слышали что нибудь про mvvmp?
Большое спасибо за такие добрые слова! По мере и сил буду дальше стараться рассказывать про разное. Про WPF и Winforms - к сожалению мне будет трудно рассказывать ибо этим я никогда не занимался Про mvvmp - конкретно не слышал, но слышал про различные модификации mvvm. Наверное mvvmp - это очередная прокачанная версия)
Для меня твои видео это золото, я на 2 курсе колледжа начал учиться и уже 1.5 лет как учу программирование. Было просвещение когда после python начал учить С++ и стало как-то более все по "программистски". Потом выучил ООП, и понял что можно делать свои объекты и задавать им поведение. И я думал что этого хватит что бы программировать что захочешь. Но вот последние 2 месяца я начал учить потерны и архитектуру приложений. И ваш канал это просто чудо. +думаю написать свою игру, где будет весь интерфейс построен на UI, и тут без MVx уже некуда. Надеюсь своим комментарием продвину видосы ваши, удачи))
Спасибо большое за контент. Материал на уровне+мемы кайф. Я не видел роликов с такой подачей(а с ивлеевой в начале я просто выпал, за подбор мемов +100500 респекта). Когда я разрабатывал меню для игры с вводом username на mvc было куча вопросов и я рад, что это видео дало понимание и я больше не буду страдать подобным(кста, сам пишу не на шарпах). Не останавливайся, такого реально на русском айти ютубе не хватает👍
Привет! Спасибо за уроки! 13:00 Можно сделать так: на 3D объект прикрепить Компонент (например, обозвав его UserClickCatcher) и Collider, в этом компоненте добавить юнитивский метод OnMouseUp(). Это вместо рейкастов.
Здравствуйте, подскажите пожалуйста, при использовании архитектуры MVP, у нас бизнес логика обрабатывается внутри модели ? в презентере? или в отельных "сервисах" или та логика которая работает с данными в модели, та что соединяет вью с моделью в презентере, а так что не относиться ни к первому не ко второму в сервисах?
Для себя, при программировании на WindowsForm, выработал такую схему: гл. форму через интерфейс инжектирую в презентер. В самом презентере нет никакой логики, только свойства интерфейсов, реализованных в гл. форме и в других формах, диалогах К примеру public ISettingsForm ISettings { get; private set; } = new Settings(); Наконец инжектирую сам презентер в модель Таким образом модель через свойства презентера может общаться со всеми формами, диалогами посредством соответствующих интерфейсов Может такой подход нарушает некие принципы ООП и т.п. но на мой взгляд, удобен
В целом всё круто, но с тем, что в разработке приложений больше подходит supervising controller, чем passive view, не согласен. Мне лично гораздо удобней работать со вторым. Да и в Unity примерах везде используется именно passive view.
Спасибо за видео! Как раз поможет для инвентаря в моей игре (сделал MVC и тупил на счёт view). Жду следующие видосы. Только вот мне интересно на счёт MVA - есть ли в нём вообше смысл, если есть MPV-Passive?
Так как никто не представлял официально MVA, то судя по интернет-ресурсам есть двойственное его определение. Кто-то на сайтах пишет что MVA это как MVC, только модель не кидает сигналы на вид, а делает это через контроллера. С другой стороны, если посмотреть на схемы на этих же ресурсах, то да, они все рисуют MVP-Passive(ибо с View прилетают ивенты UI). Короче всё смешалось в одну кучу. Но я бы наверное считал что изначально MVA это именно вариант MVC, а не MVP
Как думаете, можно ли заменить связи между модулями? То есть вместо вызова метода другого модуля просто активировать событие. Например, при нажатии на кнопку, мы не вызываем метод внутри презентера, а ставим событие. Презентер подписан на него, что-то делает внутри себя, потом активирует событие, на которое подписана Модель, а в модели при изменении свойства, например, тоже есть событие, на которое подписан уже Вью. Это для того, чтобы модули не знали о функционале друг друга. Но тогда получается у меня, что Презентер должен знать и о Вью, и о Модели (чтобы обрабатывать данные в ответ на действия с UI). UPD: для ясности - по моей логике, события так же обновляют данные модулей. Есть у нас, допустим, инвентарь. Пользователь удалил 1 экземпляр предмета по UIкнопке предмет, передалось событие в Презентер, он обработал, удалил нужное кол-во предметов и теперь вызывает Action. Модель меняет число предметов и вызывает событие на обновление визуала, которое содержит данный класс слота. Вью берет нужные данные из класса слота и так по кругу
@@sergeykazantsev1655 мне просто показалось, что нарушается SRP при подходе из видео. По идее же Вью не должен отвечать за логику, не должен вызывать метод из Презентера. Это так или я что-то не так понял?
Вызов метода не является нарушением SRP. Многие классы имеют публичные методы, которые могут вызывать другие классы, и приватные(про protected тоже не стоит забывать) которые работают с логикой внутри. Получается, если ваше предположение продолжать, то публичные методы использовать нельзя. SRP говорит про то что одна логика должна изменяться в одном месте а не в разных
У меня появился вопрос. Если мы хотим добавить StateMachine, то есть ли где-то примеры где мы соединяем StateMachine&MVP. В моем понимании, мы добавляем хранение текущего состояния в Model с возможностью изменения, а View-ов мы можем иметь несколько выход, ну или несколько Presenter если сменять реализацию? Есть ли где-нибудь ссылка на пример их реализации вместе?
У меня к сожалению не было опыта в сочетании StateMachine и MVP. Но вообще то, что вы говорите очень похоже на правду, я бы делал наверное как то так же. State лежал бы в модели, а Presenter-ы постоянно бы переключались. Пока что у меня примеров такой реализации нет, может как нибудь попробую, звучит интересно
Спасибо за видео. Хотелось бы узнать как это выглядит в чуть более сложном примере, когда есть хотя бы две сущности которые между собой могут как-то взаимодействовать. Например объект игрока и какой-то интерактивный объект, с которым он может взаимодействовать если встанет перед ним. Я не совсем понимаю как происходит коммуникация между ними. Догадываюсь что взаимодействие будет происходить через View обоих объектов. PlayerView получает InteractiveObjectView объекта например с помощью рейкаста. А что дальше? Передаем InteractiveObjectView в PlayerPresenter чтобы вызвать реакцию объекта оттуда? Как-то выглядит не очень что PlayerView будет работать с InteractiveObjectView. В общем все хорошо понятно в рамках одной маленькой системы (например Player), но при их взаимодействии мне не очень понятно как это выглядит.
Однозначного ответа на это нет. Я вижу одно теоретическое и одно практическое решение. Теоретическое гласит о том, что на самом деле вид отвечает только за представление, а логика взаимодействия - это уровень презентера, посему надо не использовать монобех и всю юнитишную физику и играться с координатами и сравнивая позицию игрока и интерактивного контроллера чистой математикой, и работать на их уровне. Вроде какая то крупная фирма типа EPAM-а просит на MVP написать тестовое и там как раз они хотят чтобы самолётик летал без использования физики. Такой код будет легко перекинуть на другую платформу, но мне кажется это не столь эффективно и бессмысленное ограничение себя(если конечно нет спец условий) Практическое гласит о том, что я бы во View хранил ссылку на Presenter и я бы сделал так - если сработал условный OnTriggerEnter, я бы во View дёргал метод _presenter.OnInteract(); Авторы MVC и MVP гласят что не надо придерживаться ордотоксальности и подстраивать эти паттерны под себя совершенно нормально Также я лично очень люблю такие кейсы решать через ивенты. Отправить статичный ивент а какой-нибудь менеджер его где-то правильно обработает: и объект уберёт и Player-у прибавит или убавит жизней На последних двух видео я опубликовал новую игру про шаурму, там используется MVVM, видео на эту тему пока нет но можете посмотреть гитхаб, думаю вы пойметё как я организовал связь между Model, View и ViewModel
@@sergeykazantsev1655 спасибо большое за ответ. Я согласен, что не использовать возможности движка - бессмысленно. Поэтому я сделал механику определения цели в своем примере через рейкаст. Но все же не совсем понял что делать дальше. Получается что презентер должен работать с презентером цели. И я застрял не понимая как его грамотно передать. Получается он должен пройти через два view прежде чем он попадет куда надо (метод в презентере игрока) Еще меня смущает то что view и presenter во многих примерах имеют ссылки друг на друга (оба зависят друг от друга). Я не уверен, но это похоже на нарушение принципов solid.
@@sergeykazantsev1655 еще была такая мысль. Поправьте пожалуйста, если я ошибаюсь. Если в MVP инпут обрабатывает view, то можно ли считать что вызов эффекта объекта-цели (например открыть дверь перед игроком) это своего рода инпут в контексте этой двери? Только инициатором теперь является не InputSystem, а объект Player? Получается дверь просто реагирует на какой-то внешний инпут сигнал (кто-то сказал есть открыться). Есть ощущение что это еще сильнее разделяет системы и делает их абсолютной независимыми друг от друга. Возможно меня просто понесло. Надеюсь понятно сформулировал.
Я вообще не уверен что конкретно игрока и препятствия засовывать в MVP хорошая идея. В этом есть какая-то потребность именно в вашей задаче? Обычно MV* для игрока делается если это сетевая игра, но тогда и вся физика считается на сервере, а на клиенте игрок лишь болванка. Или я часто использую MVVM для диалогов и UI-элементов Если всё таки продолжать использовать MVP в вашем случае то да, пролезания в два View не избежать. Я бы сделал ивент в котором бы передавал presenter игрока и объекта, и сделал бы какой-то InteractableController который бы слушал это ивент и потом с этими бы presenter-ами что-то делал. А какие принципы SOLID нарушаются по вашему, если view и presenter имеют ссылки друг на друга?
@@sergeykazantsev1655 да, сейчас перечитал про SOLID и действительно, такого там нет. Но мне казалось что делать прямую двустороннюю связь - плохая идея, и лучше делать так что один знает второго и подписывается на его события, но второй не может напрямую работать с первым. Про MV* архитектуру: я подумал что будет правильно придерживаться одного паттерна во всей системе для консистентности (возможно кроме UI). Все равно же у многих объектов на сцене есть какая-то игровая логика, которую хочется отделить от представления (MonoBehaviour). Поэтому я решил попробовать известные решения и выбрал для MVP на попробовать. Но возможно этим я слишком усложняю код.
У меня вопрос, если я буду писать логику магазина и модель с вьюшкой у меня разбухают, мне получается нужно разделять на несколько моделей и view, отвечающие за разные вещи в магазине? Я пришел к тому что есть один презентер, который хранит в себе все модели, а каждая модель уведомляет свой view. Но может ли одна модель хранить в себе несколько view?
Мне кажется незазорным на одну модель сделать несколько presenter-ов и view, каждый из которых приаттачен к своему presenter-у Тут же главное чтобы вам было удобно)
@@sergeykazantsev1655я делаю пет-проект и хочется как-то улучшить свою архитектуру, но как я понял в данном случае главное, чтобы было удобно поддерживать это все
Ну вот, получается можно) Но если допустим те же слоты вылить на терминалы типа однорукого бандита + web игры - всё равно универсальный контроллер будет проблематично написать :)
6:18 о (состоянии в модели) -если модель хранит, например, выделение элементов, то нельзя в 2 окнах редактировать один файл, да и частое обновление модели неэффективно. Лучше в Presenter вынести
Zenject буду косвенно упоминать, это очень мощный инструмент, там куча всего, я боюсь не смогу прям полноценно его раскрыть :) ECS не знаю, я про него много читал, но у меня нет практического опыта с ним, чтобы сказать, что хорошо, что плохо. Возможно, со временем, если канал получится вести долго, я до них обоих доползу)
@@sergeykazantsev1655 да кто такой этот ваш Zenject? Его упоминают в комментах почти под каждым видео. Запрашиваю хотя бы вводное видео, с описанием, какие проблемы и насколько хорошо решает.
Привет, а почему в Passive View вьюха активная и сама вызывает контроллер, хотя по названию паттерна она должна быть пассивной? Просто есть другие объяснения схемы и там показывают, что в Passive View модель ивенты шлет в презентер и вьюха получает ивент от презентера, активный только презентер, все остальное на ивентах
Насколько я могу судить, подразумевается что вид считается пассивным если он не завязан на модель. Отсылать ивенты или вызывать контроллер и говорить ему что что-то изменилось как я понимаю допустимо Материал брал отсюда martinfowler.com/eaaDev/PassiveScreen.html
Цитата самого Фаулера The significant change with Passive View is that the view is made completely passive and is no longer responsible for updating itself from the model.
Привет! Все верно. Я как понимаю это пошло от Мартина Фаулера, но если загуглить, все пишут именно supervising controller для модели MVP. Если загуглить MVP - supervising - на нескольких сайтах и статьях будет именно controller Вот блог фаулера martinfowler.com/eaaDev/SupervisingPresenter.html How it Works Supervising Controller decomposes presentation functionality into two parts: a controller (often called presenter) and view. Вот MSDN learn.microsoft.com/en-us/archive/msdn-magazine/2010/september/msdn-magazine-cutting-edge-better-web-forms-with-the-mvp-pattern That’s up to you. In response to these kinds of questions, the MVP pattern has been split in two separate patterns-Supervising Controller and Passive View-whose primary difference is just the amount of code in the view.
09:30 , причина явно не в этом, т.к. в вебе ровно тот же инструментарий, что и в мобильной разработке: реактивные компоненты, обновляющиеся с изменением стейта
@@sergeykazantsev1655 , а хрен его знает :) Может быть и с веба пошло, просто с дореактивной поры, когда все сайты, по сути, отдавались через server side rendering(привет php)
Блин чувак, ты очень крут, я всю голову сломал над тем как прикрутить классический mvc к интерфейсу пользователя, очень помог! Как говорится, Майк потел и нам велел
По классике благодарим за качественный контент (Специально пишу побольше, говорят алгоритмам это дело нравится)
Да и мне тоже)
Самые качественные объяснение неочевидных тем на русскоязычном ютубе. Это лайк и саб, очевидно.
Контент супер, подача огонь! Давно пытаюсь разобраться с разнообразными технологиями построения графических приложений( winforms, wpf ...) и прилогающимся к ним паттернам. Автор нашёл компромис демонстрируя данные технологии на примерах работы с движком unity причём в таком изложение, что становится понятно как всё это перенести на вышеперечисленные десктопные инструменты разработки. Так можно и всё ООП по полочкам разложить😊 что очень актуально, учитывая как мно литературы в наше время и сколько времени нужно тратить чтобы докопаться до истины (не все могут себе это позволить работая по совсем другому профилю). Автору огромное спасибо за материал! Он однозначно годный, т.к преподносится не только структура и правила пользования данным шаблоном, но и рассуждения о причинах перехода к данной технологии, а также суть самой идеи, что соответственно заставляет голову думать, а не просто зазубривать очередной шаблон как аксиому, не развивая объектное мышление что является нормой для начинающих джунов в наши дни. Мне как начинающему джуну остается надеятся что будет больше подобного контента и что автор на гитхабе будет выкладывать проекты не только на unity, но и реализации на других технологиях разработки типа winforms и wpf, всё таки на таких исходниках потыкать былобы куда проще 😅 но это пожелание 😊 а вы слышали что нибудь про mvvmp?
Большое спасибо за такие добрые слова! По мере и сил буду дальше стараться рассказывать про разное.
Про WPF и Winforms - к сожалению мне будет трудно рассказывать ибо этим я никогда не занимался
Про mvvmp - конкретно не слышал, но слышал про различные модификации mvvm. Наверное mvvmp - это очередная прокачанная версия)
Как я понимаю Майка... сам сижу сейчас, офигеваю. Так еще и жара, лето
Для меня твои видео это золото, я на 2 курсе колледжа начал учиться и уже 1.5 лет как учу программирование. Было просвещение когда после python начал учить С++ и стало как-то более все по "программистски". Потом выучил ООП, и понял что можно делать свои объекты и задавать им поведение. И я думал что этого хватит что бы программировать что захочешь. Но вот последние 2 месяца я начал учить потерны и архитектуру приложений. И ваш канал это просто чудо. +думаю написать свою игру, где будет весь интерфейс построен на UI, и тут без MVx уже некуда. Надеюсь своим комментарием продвину видосы ваши, удачи))
Спасибо)
Очень долго не мог понять как прикрутить MVC к ВинФормам, а оказалось можно изменить паттерн) Спасибо!
Я все гадал в чем же отличие MVC и MVP а Вы все по полочкам расставили, вот это мощь!
Огонь, понятно объяснено и хороший пример, спасибо!)
Спасибо большое за контент. Материал на уровне+мемы кайф. Я не видел роликов с такой подачей(а с ивлеевой в начале я просто выпал, за подбор мемов +100500 респекта). Когда я разрабатывал меню для игры с вводом username на mvc было куча вопросов и я рад, что
это видео дало понимание и я больше не буду страдать подобным(кста, сам пишу не на шарпах). Не останавливайся, такого реально на русском айти ютубе не хватает👍
Спасибо за видео, он помог мне понять сложный (а по итогу легкий) концепт.
Офигенное видео. Спасибо большое!
Привет! Спасибо за уроки!
13:00 Можно сделать так: на 3D объект прикрепить Компонент (например, обозвав его UserClickCatcher) и Collider, в этом компоненте добавить юнитивский метод OnMouseUp().
Это вместо рейкастов.
Пример не совсем удачный, но задумка была в том что универсального решения в некоторых случаях нет
Ты крут, теперь ждёт MVVM!
Здравствуйте, подскажите пожалуйста, при использовании архитектуры MVP, у нас бизнес логика обрабатывается внутри модели ? в презентере? или в отельных "сервисах" или та логика которая работает с данными в модели, та что соединяет вью с моделью в презентере, а так что не относиться ни к первому не ко второму в сервисах?
Для себя, при программировании на WindowsForm, выработал такую схему:
гл. форму через интерфейс инжектирую в презентер. В самом презентере нет никакой логики, только свойства интерфейсов, реализованных в гл. форме и в других формах, диалогах
К примеру
public ISettingsForm ISettings { get; private set; } = new Settings();
Наконец инжектирую сам презентер в модель
Таким образом модель через свойства презентера может общаться со всеми формами, диалогами посредством соответствующих интерфейсов
Может такой подход нарушает некие принципы ООП и т.п. но на мой взгляд, удобен
Мне кажется, вообще mv* паттерны не сильно используют ООП принципы, так что ваше решение мне кажется нормальным
@@sergeykazantsev1655 Я любитель, потому мнение профессионала для меня определённо важно, спасибо!
Спасибо! Ждём
Чётко 🔥
Я всё не мог понять семейство MV и думал на кой всё это, а оно вон оно че)
Эххх, это бы видео показать мне лет двадцать назад!
посмотрел все ваши видосы и понял, что лучше объяснений и не найти) у вас очень классный подход к подаче информации. жду видео про mvvm и zenject
Годно!
В целом всё круто, но с тем, что в разработке приложений больше подходит supervising controller, чем passive view, не согласен. Мне лично гораздо удобней работать со вторым. Да и в Unity примерах везде используется именно passive view.
Спасибо за видео! Как раз поможет для инвентаря в моей игре (сделал MVC и тупил на счёт view). Жду следующие видосы.
Только вот мне интересно на счёт MVA - есть ли в нём вообше смысл, если есть MPV-Passive?
Так как никто не представлял официально MVA, то судя по интернет-ресурсам есть двойственное его определение.
Кто-то на сайтах пишет что MVA это как MVC, только модель не кидает сигналы на вид, а делает это через контроллера.
С другой стороны, если посмотреть на схемы на этих же ресурсах, то да, они все рисуют MVP-Passive(ибо с View прилетают ивенты UI). Короче всё смешалось в одну кучу.
Но я бы наверное считал что изначально MVA это именно вариант MVC, а не MVP
В MVC представление тоже может посылать контроллеру сигналы, даже не имея ссылки на него: можно использовать функции обратного вызова.
Ну сейчас то да, этому никто не мешает. Насколько я понимаю, в момент когда был представлен MVC никаких функций обратного вызова не существовало)
Как думаете, можно ли заменить связи между модулями? То есть вместо вызова метода другого модуля просто активировать событие. Например, при нажатии на кнопку, мы не вызываем метод внутри презентера, а ставим событие. Презентер подписан на него, что-то делает внутри себя, потом активирует событие, на которое подписана Модель, а в модели при изменении свойства, например, тоже есть событие, на которое подписан уже Вью.
Это для того, чтобы модули не знали о функционале друг друга. Но тогда получается у меня, что Презентер должен знать и о Вью, и о Модели (чтобы обрабатывать данные в ответ на действия с UI).
UPD: для ясности - по моей логике, события так же обновляют данные модулей. Есть у нас, допустим, инвентарь. Пользователь удалил 1 экземпляр предмета по UIкнопке предмет, передалось событие в Презентер, он обработал, удалил нужное кол-во предметов и теперь вызывает Action. Модель меняет число предметов и вызывает событие на обновление визуала, которое содержит данный класс слота. Вью берет нужные данные из класса слота и так по кругу
Можно. И я вас поздравляю, вы практически изобрели MVVM :) там как раз к этому и пришли
@@sergeykazantsev1655 мне просто показалось, что нарушается SRP при подходе из видео. По идее же Вью не должен отвечать за логику, не должен вызывать метод из Презентера. Это так или я что-то не так понял?
Вызов метода не является нарушением SRP. Многие классы имеют публичные методы, которые могут вызывать другие классы, и приватные(про protected тоже не стоит забывать) которые работают с логикой внутри. Получается, если ваше предположение продолжать, то публичные методы использовать нельзя.
SRP говорит про то что одна логика должна изменяться в одном месте а не в разных
У меня появился вопрос. Если мы хотим добавить StateMachine, то есть ли где-то примеры где мы соединяем StateMachine&MVP. В моем понимании, мы добавляем хранение текущего состояния в Model с возможностью изменения, а View-ов мы можем иметь несколько выход, ну или несколько Presenter если сменять реализацию? Есть ли где-нибудь ссылка на пример их реализации вместе?
У меня к сожалению не было опыта в сочетании StateMachine и MVP. Но вообще то, что вы говорите очень похоже на правду, я бы делал наверное как то так же. State лежал бы в модели, а Presenter-ы постоянно бы переключались. Пока что у меня примеров такой реализации нет, может как нибудь попробую, звучит интересно
Спасибо за видео.
Хотелось бы узнать как это выглядит в чуть более сложном примере, когда есть хотя бы две сущности которые между собой могут как-то взаимодействовать. Например объект игрока и какой-то интерактивный объект, с которым он может взаимодействовать если встанет перед ним. Я не совсем понимаю как происходит коммуникация между ними. Догадываюсь что взаимодействие будет происходить через View обоих объектов. PlayerView получает InteractiveObjectView объекта например с помощью рейкаста. А что дальше? Передаем InteractiveObjectView в PlayerPresenter чтобы вызвать реакцию объекта оттуда? Как-то выглядит не очень что PlayerView будет работать с InteractiveObjectView.
В общем все хорошо понятно в рамках одной маленькой системы (например Player), но при их взаимодействии мне не очень понятно как это выглядит.
Однозначного ответа на это нет. Я вижу одно теоретическое и одно практическое решение.
Теоретическое гласит о том, что на самом деле вид отвечает только за представление, а логика взаимодействия - это уровень презентера, посему надо не использовать монобех и всю юнитишную физику и играться с координатами и сравнивая позицию игрока и интерактивного контроллера чистой математикой, и работать на их уровне. Вроде какая то крупная фирма типа EPAM-а просит на MVP написать тестовое и там как раз они хотят чтобы самолётик летал без использования физики. Такой код будет легко перекинуть на другую платформу, но мне кажется это не столь эффективно и бессмысленное ограничение себя(если конечно нет спец условий)
Практическое гласит о том, что я бы во View хранил ссылку на Presenter и я бы сделал так - если сработал условный OnTriggerEnter, я бы во View дёргал метод _presenter.OnInteract();
Авторы MVC и MVP гласят что не надо придерживаться ордотоксальности и подстраивать эти паттерны под себя совершенно нормально
Также я лично очень люблю такие кейсы решать через ивенты. Отправить статичный ивент а какой-нибудь менеджер его где-то правильно обработает: и объект уберёт и Player-у прибавит или убавит жизней
На последних двух видео я опубликовал новую игру про шаурму, там используется MVVM, видео на эту тему пока нет но можете посмотреть гитхаб, думаю вы пойметё как я организовал связь между Model, View и ViewModel
@@sergeykazantsev1655 спасибо большое за ответ. Я согласен, что не использовать возможности движка - бессмысленно. Поэтому я сделал механику определения цели в своем примере через рейкаст. Но все же не совсем понял что делать дальше. Получается что презентер должен работать с презентером цели. И я застрял не понимая как его грамотно передать. Получается он должен пройти через два view прежде чем он попадет куда надо (метод в презентере игрока)
Еще меня смущает то что view и presenter во многих примерах имеют ссылки друг на друга (оба зависят друг от друга). Я не уверен, но это похоже на нарушение принципов solid.
@@sergeykazantsev1655 еще была такая мысль. Поправьте пожалуйста, если я ошибаюсь.
Если в MVP инпут обрабатывает view, то можно ли считать что вызов эффекта объекта-цели (например открыть дверь перед игроком) это своего рода инпут в контексте этой двери? Только инициатором теперь является не InputSystem, а объект Player? Получается дверь просто реагирует на какой-то внешний инпут сигнал (кто-то сказал есть открыться). Есть ощущение что это еще сильнее разделяет системы и делает их абсолютной независимыми друг от друга. Возможно меня просто понесло. Надеюсь понятно сформулировал.
Я вообще не уверен что конкретно игрока и препятствия засовывать в MVP хорошая идея. В этом есть какая-то потребность именно в вашей задаче?
Обычно MV* для игрока делается если это сетевая игра, но тогда и вся физика считается на сервере, а на клиенте игрок лишь болванка. Или я часто использую MVVM для диалогов и UI-элементов
Если всё таки продолжать использовать MVP в вашем случае то да, пролезания в два View не избежать. Я бы сделал ивент в котором бы передавал presenter игрока и объекта, и сделал бы какой-то InteractableController который бы слушал это ивент и потом с этими бы presenter-ами что-то делал.
А какие принципы SOLID нарушаются по вашему, если view и presenter имеют ссылки друг на друга?
@@sergeykazantsev1655 да, сейчас перечитал про SOLID и действительно, такого там нет. Но мне казалось что делать прямую двустороннюю связь - плохая идея, и лучше делать так что один знает второго и подписывается на его события, но второй не может напрямую работать с первым.
Про MV* архитектуру: я подумал что будет правильно придерживаться одного паттерна во всей системе для консистентности (возможно кроме UI). Все равно же у многих объектов на сцене есть какая-то игровая логика, которую хочется отделить от представления (MonoBehaviour). Поэтому я решил попробовать известные решения и выбрал для MVP на попробовать. Но возможно этим я слишком усложняю код.
У меня вопрос, если я буду писать логику магазина и модель с вьюшкой у меня разбухают, мне получается нужно разделять на несколько моделей и view, отвечающие за разные вещи в магазине? Я пришел к тому что есть один презентер, который хранит в себе все модели, а каждая модель уведомляет свой view. Но может ли одна модель хранить в себе несколько view?
Мне кажется незазорным на одну модель сделать несколько presenter-ов и view, каждый из которых приаттачен к своему presenter-у
Тут же главное чтобы вам было удобно)
@@sergeykazantsev1655я делаю пет-проект и хочется как-то улучшить свою архитектуру, но как я понял в данном случае главное, чтобы было удобно поддерживать это все
ну да, "удобно вам"="удобно вам расширять и поддерживать"
На счёт считывания клика для ui и 3d, можно же использовать интерфейс IPointerClickHandler он работает во всех случаях
Ну вот, получается можно) Но если допустим те же слоты вылить на терминалы типа однорукого бандита + web игры - всё равно универсальный контроллер будет проблематично написать :)
6:18 о (состоянии в модели)
-если модель хранит, например, выделение элементов, то нельзя в 2 окнах редактировать один файл, да и частое обновление модели неэффективно. Лучше в Presenter вынести
Собственно к этому в mvvm и пришли) я лишь показал как это предложил автор MVP)
лукас тебе, добрый человек. Планируешь ли ты в будущем затрагивать в своих роликах фреймворки типа Zenject и ECS?) было бы интересно посмотреть
Zenject буду косвенно упоминать, это очень мощный инструмент, там куча всего, я боюсь не смогу прям полноценно его раскрыть :) ECS не знаю, я про него много читал, но у меня нет практического опыта с ним, чтобы сказать, что хорошо, что плохо. Возможно, со временем, если канал получится вести долго, я до них обоих доползу)
@@sergeykazantsev1655 да кто такой этот ваш Zenject? Его упоминают в комментах почти под каждым видео. Запрашиваю хотя бы вводное видео, с описанием, какие проблемы и насколько хорошо решает.
Привет, а почему в Passive View вьюха активная и сама вызывает контроллер, хотя по названию паттерна она должна быть пассивной? Просто есть другие объяснения схемы и там показывают, что в Passive View модель ивенты шлет в презентер и вьюха получает ивент от презентера, активный только презентер, все остальное на ивентах
Насколько я могу судить, подразумевается что вид считается пассивным если он не завязан на модель. Отсылать ивенты или вызывать контроллер и говорить ему что что-то изменилось как я понимаю допустимо
Материал брал отсюда martinfowler.com/eaaDev/PassiveScreen.html
Цитата самого Фаулера
The significant change with Passive View is that the view is made completely passive and is no longer responsible for updating itself from the model.
Привет! Я правильно понял что в примере у тебя Supervising controller MVP?
Кстати странно что не Supervising presenter называется.
Привет! Все верно.
Я как понимаю это пошло от Мартина Фаулера, но если загуглить, все пишут именно supervising controller для модели MVP. Если загуглить MVP - supervising - на нескольких сайтах и статьях будет именно controller
Вот блог фаулера martinfowler.com/eaaDev/SupervisingPresenter.html
How it Works
Supervising Controller decomposes presentation functionality into two parts: a controller (often called presenter) and view.
Вот MSDN
learn.microsoft.com/en-us/archive/msdn-magazine/2010/september/msdn-magazine-cutting-edge-better-web-forms-with-the-mvp-pattern
That’s up to you. In response to these kinds of questions, the MVP pattern has been split in two separate patterns-Supervising Controller and Passive View-whose primary difference is just the amount of code in the view.
09:30 , причина явно не в этом, т.к. в вебе ровно тот же инструментарий, что и в мобильной разработке: реактивные компоненты, обновляющиеся с изменением стейта
А в чём же тогда, по вашему мнению? Я без негатива, мне искренне интересно, вебом никогда не занимался
@@sergeykazantsev1655 , а хрен его знает :)
@@sergeykazantsev1655 , а хрен его знает :)
Может быть и с веба пошло, просто с дореактивной поры, когда все сайты, по сути, отдавались через server side rendering(привет php)
i need eng...
I guess I will translate it someday...