Model View Presenter, MVP, Модель Вид Представитель, С#, Unity
HTML-код
- Опубликовано: 28 июн 2024
- А вот и Model View Presenter подъехал!
Гитхаб на проект с демкой из видео: github.com/Haywaar/PatternDem...
Лежит по пути Assets/Patterns/MVPExample
Автору на кофе и шаурму
4276 5500 5792 8742 - карта Сбербанка
Если будут вопросы
мой тг @wargy
моя почта kazancev.s215@gmail.com
Тайминги
00:00 Введение
00:28 MV* - семейства
00:48 Дисклеймер
01:16 Проблема MVC
03:03 Проблема MVC на примере с геймдева
03:54 MVP - определение
04:50 MVP vs MVC, схемы ролей
06:37 Варианты MVP(Passive View и Supervising Controller)
09:35 UML схемы MVP и MVC
10:52 Конкретный пример: введение
12:00 Конкретный пример: анализ проблемы
13:16 Конкретный пример: рефакторим View
13:42 Конкретный пример: рефакторим UIView
14:20 Конкретный пример: рефакторим 3DView
14:52 Конкретный пример: пишем Presenter
15:32 Конкретный пример: Model не изменилась
15:53 Конкретный пример: правим MainScript
16:00 Когда использовать MVP?
17:07 Финал 
Игры
Как я понимаю Майка... сам сижу сейчас, офигеваю. Так еще и жара, лето
Блин чувак, ты очень крут, я всю голову сломал над тем как прикрутить классический mvc к интерфейсу пользователя, очень помог! Как говорится, Майк потел и нам велел
Самые качественные объяснение неочевидных тем на русскоязычном ютубе. Это лайк и саб, очевидно.
По классике благодарим за качественный контент (Специально пишу побольше, говорят алгоритмам это дело нравится)
Да и мне тоже)
Огонь, понятно объяснено и хороший пример, спасибо!)
посмотрел все ваши видосы и понял, что лучше объяснений и не найти) у вас очень классный подход к подаче информации. жду видео про mvvm и zenject
Очень долго не мог понять как прикрутить MVC к ВинФормам, а оказалось можно изменить паттерн) Спасибо!
Спасибо за видео, он помог мне понять сложный (а по итогу легкий) концепт.
Офигенное видео. Спасибо большое!
Ты крут, теперь ждёт MVVM!
Спасибо! Ждём
Для меня твои видео это золото, я на 2 курсе колледжа начал учиться и уже 1.5 лет как учу программирование. Было просвещение когда после python начал учить С++ и стало как-то более все по "программистски". Потом выучил ООП, и понял что можно делать свои объекты и задавать им поведение. И я думал что этого хватит что бы программировать что захочешь. Но вот последние 2 месяца я начал учить потерны и архитектуру приложений. И ваш канал это просто чудо. +думаю написать свою игру, где будет весь интерфейс построен на UI, и тут без MVx уже некуда. Надеюсь своим комментарием продвину видосы ваши, удачи))
Спасибо)
Чётко 🔥
Привет! Спасибо за уроки!
13:00 Можно сделать так: на 3D объект прикрепить Компонент (например, обозвав его UserClickCatcher) и Collider, в этом компоненте добавить юнитивский метод OnMouseUp().
Это вместо рейкастов.
Пример не совсем удачный, но задумка была в том что универсального решения в некоторых случаях нет
Годно!
Я всё не мог понять семейство MV и думал на кой всё это, а оно вон оно че)
Спасибо за видео! Как раз поможет для инвентаря в моей игре (сделал MVC и тупил на счёт view). Жду следующие видосы.
Только вот мне интересно на счёт MVA - есть ли в нём вообше смысл, если есть MPV-Passive?
Так как никто не представлял официально MVA, то судя по интернет-ресурсам есть двойственное его определение.
Кто-то на сайтах пишет что MVA это как MVC, только модель не кидает сигналы на вид, а делает это через контроллера.
С другой стороны, если посмотреть на схемы на этих же ресурсах, то да, они все рисуют MVP-Passive(ибо с View прилетают ивенты UI). Короче всё смешалось в одну кучу.
Но я бы наверное считал что изначально MVA это именно вариант MVC, а не MVP
Для себя, при программировании на WindowsForm, выработал такую схему:
гл. форму через интерфейс инжектирую в презентер. В самом презентере нет никакой логики, только свойства интерфейсов, реализованных в гл. форме и в других формах, диалогах
К примеру
public ISettingsForm ISettings { get; private set; } = new Settings();
Наконец инжектирую сам презентер в модель
Таким образом модель через свойства презентера может общаться со всеми формами, диалогами посредством соответствующих интерфейсов
Может такой подход нарушает некие принципы ООП и т.п. но на мой взгляд, удобен
Мне кажется, вообще mv* паттерны не сильно используют ООП принципы, так что ваше решение мне кажется нормальным
@@sergeykazantsev1655 Я любитель, потому мнение профессионала для меня определённо важно, спасибо!
В MVC представление тоже может посылать контроллеру сигналы, даже не имея ссылки на него: можно использовать функции обратного вызова.
Ну сейчас то да, этому никто не мешает. Насколько я понимаю, в момент когда был представлен MVC никаких функций обратного вызова не существовало)
На счёт считывания клика для ui и 3d, можно же использовать интерфейс IPointerClickHandler он работает во всех случаях
Ну вот, получается можно) Но если допустим те же слоты вылить на терминалы типа однорукого бандита + web игры - всё равно универсальный контроллер будет проблематично написать :)
лукас тебе, добрый человек. Планируешь ли ты в будущем затрагивать в своих роликах фреймворки типа Zenject и ECS?) было бы интересно посмотреть
Zenject буду косвенно упоминать, это очень мощный инструмент, там куча всего, я боюсь не смогу прям полноценно его раскрыть :) ECS не знаю, я про него много читал, но у меня нет практического опыта с ним, чтобы сказать, что хорошо, что плохо. Возможно, со временем, если канал получится вести долго, я до них обоих доползу)
@@sergeykazantsev1655 да кто такой этот ваш Zenject? Его упоминают в комментах почти под каждым видео. Запрашиваю хотя бы вводное видео, с описанием, какие проблемы и насколько хорошо решает.
Привет! Я правильно понял что в примере у тебя 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.
У меня появился вопрос. Если мы хотим добавить StateMachine, то есть ли где-то примеры где мы соединяем StateMachine&MVP. В моем понимании, мы добавляем хранение текущего состояния в Model с возможностью изменения, а View-ов мы можем иметь несколько выход, ну или несколько Presenter если сменять реализацию? Есть ли где-нибудь ссылка на пример их реализации вместе?
У меня к сожалению не было опыта в сочетании StateMachine и MVP. Но вообще то, что вы говорите очень похоже на правду, я бы делал наверное как то так же. State лежал бы в модели, а Presenter-ы постоянно бы переключались. Пока что у меня примеров такой реализации нет, может как нибудь попробую, звучит интересно
6:18 о (состоянии в модели)
-если модель хранит, например, выделение элементов, то нельзя в 2 окнах редактировать один файл, да и частое обновление модели неэффективно. Лучше в Presenter вынести
Собственно к этому в mvvm и пришли) я лишь показал как это предложил автор MVP)
Как думаете, можно ли заменить связи между модулями? То есть вместо вызова метода другого модуля просто активировать событие. Например, при нажатии на кнопку, мы не вызываем метод внутри презентера, а ставим событие. Презентер подписан на него, что-то делает внутри себя, потом активирует событие, на которое подписана Модель, а в модели при изменении свойства, например, тоже есть событие, на которое подписан уже Вью.
Это для того, чтобы модули не знали о функционале друг друга. Но тогда получается у меня, что Презентер должен знать и о Вью, и о Модели (чтобы обрабатывать данные в ответ на действия с UI).
UPD: для ясности - по моей логике, события так же обновляют данные модулей. Есть у нас, допустим, инвентарь. Пользователь удалил 1 экземпляр предмета по UIкнопке предмет, передалось событие в Презентер, он обработал, удалил нужное кол-во предметов и теперь вызывает Action. Модель меняет число предметов и вызывает событие на обновление визуала, которое содержит данный класс слота. Вью берет нужные данные из класса слота и так по кругу
Можно. И я вас поздравляю, вы практически изобрели MVVM :) там как раз к этому и пришли
@@sergeykazantsev1655 мне просто показалось, что нарушается SRP при подходе из видео. По идее же Вью не должен отвечать за логику, не должен вызывать метод из Презентера. Это так или я что-то не так понял?
Вызов метода не является нарушением SRP. Многие классы имеют публичные методы, которые могут вызывать другие классы, и приватные(про protected тоже не стоит забывать) которые работают с логикой внутри. Получается, если ваше предположение продолжать, то публичные методы использовать нельзя.
SRP говорит про то что одна логика должна изменяться в одном месте а не в разных
Спасибо за видео.
Хотелось бы узнать как это выглядит в чуть более сложном примере, когда есть хотя бы две сущности которые между собой могут как-то взаимодействовать. Например объект игрока и какой-то интерактивный объект, с которым он может взаимодействовать если встанет перед ним. Я не совсем понимаю как происходит коммуникация между ними. Догадываюсь что взаимодействие будет происходить через 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 на попробовать. Но возможно этим я слишком усложняю код.
Привет, а почему в 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.
09:30 , причина явно не в этом, т.к. в вебе ровно тот же инструментарий, что и в мобильной разработке: реактивные компоненты, обновляющиеся с изменением стейта
А в чём же тогда, по вашему мнению? Я без негатива, мне искренне интересно, вебом никогда не занимался
@@sergeykazantsev1655 , а хрен его знает :)
@@sergeykazantsev1655 , а хрен его знает :)
Может быть и с веба пошло, просто с дореактивной поры, когда все сайты, по сути, отдавались через server side rendering(привет php)
У меня вопрос, если я буду писать логику магазина и модель с вьюшкой у меня разбухают, мне получается нужно разделять на несколько моделей и view, отвечающие за разные вещи в магазине? Я пришел к тому что есть один презентер, который хранит в себе все модели, а каждая модель уведомляет свой view. Но может ли одна модель хранить в себе несколько view?
Мне кажется незазорным на одну модель сделать несколько presenter-ов и view, каждый из которых приаттачен к своему presenter-у
Тут же главное чтобы вам было удобно)
@@sergeykazantsev1655я делаю пет-проект и хочется как-то улучшить свою архитектуру, но как я понял в данном случае главное, чтобы было удобно поддерживать это все
ну да, "удобно вам"="удобно вам расширять и поддерживать"
i need eng...
I guess I will translate it someday...