Model View Controller, MVC, Модель Вид Контроллер, C#, Unity 

Спасибо, стараюсь вставлять смешнявочки, там где это не отвлечет внимание от важного материала)

Спасибо) как раз начал сегодня формировать материал про MVP, думал superviser view и passive vies скипнуть, но раз есть такой запрос - расскажу. Хотя там в две строчки всё описывается)

@@sergeykazantsev1655 буду ждать)

Можно задонатить на кофе и шаурму :D но и так приятно)

@@sergeykazantsev1655 как только работу найду - закину. Пока только словами, сорян)

Во-первых, на второй минуте я объяснил почему стрелочки на разных сайтах отображаются по-разному. Во-вторых, имхо, модель бармен-бочка-пиво ещё хуже моей и вот почему. В MVC есть три слоя : данные, логика и представление данных. Я предлагаю на примерах пробежаться по этим слоям и посмотреть что лучше подходит. Первый слой - данные или же модель. Модель это слой отвечающий за состояние, уведомляющий вид о своём изменении. Мой умный холодильник(а я его так описал) под это подходит - вытащили пивко - бахнули пуш на онлайн меню. В вашем примере может ли пиво, то есть хмельная жижа уведомить бармена что состояние изменилось? Нет. Отмечу, что именно пиво по каноничному MVC должна сигналить бармену. Если бармен(вид) следит за состоянием пива(модель) то это стрелочка в обратную сторону повёрнута что не канон. Далее - контроллер - логика, оно же действие или работа над данными. Задача контроллера - обрабатывать пользовательский ввод и изменять состояние модели. В моей схеме логика это бармен. Бармен принимает заказ пользователя и достаёт пивко, то есть обрабатывает пользовательский ввод и изменяет состояние холодильника. В вашей схеме - бочка с краном является прослойкой между состоянием(пивом) и видом(барменом). В вашей схеме кран обрабатывает пользовательский ввод? Вроде бы да, и состояние изменяет, вот только вопрос - а кто краник то дёргает? Посетитель? Тогда это странный бар, приходит клиент, бармен ему говорит вот пивко, хочешь наливай и пользователь сам себе льёт. Какая-то пивнуха самообслуживания получается. Или краник дёргает бармен? Тогда почему тот, кто занимается видом, занимается ещё и логикой? Ну и наконец - вид, оно же представление состояния. Задача вида - отображать состояние данных пользователю в той или иной форме и получать уведомления от модели об изменении. Меню, при условии что оно показывает какое бухлишко есть а какого нет - под это описание подходит. Но это я уже спрашивал - как бармен(вид) узнаёт об изменении состояния пива? При условии что его должны уведомить а не выяснить это сам? Отвечая на вопрос "а что если пользователь напрямую полезет в холодос" - хочу спросить - а вы часто в баре или ресторане проходите на кухню и достаёте жратву из секции где сидят повара? Или часто в баре вы заходите за барную стойку и сами берёте алкоголь и наливаете себе в стакан. Что в жизни что в коде это нарушение заданного контракта и соглашений. Я могу также спросить - "А что если бармен вырвет кран и будет из дырки наливать пивко?" Структура не изменится, стакан наполнить получится, а один из трёх компонентов пропал. Вопрос такой смысла не имеет. Ну и под финалочку, да, в описании есть небольшой косяк ибо в каноничном MVC контроллер не взаимодействует с видом. Я написал об этой коммент в закрепе под этим видео. И потому стрелочки "консультирует пользователя по меню" не должно быть. Тут я накосячил, каюсь. И раз этой стрелочки нет можно поискать другую аналогию, но пока её я не придумал. Если придумаете - возможно в версии 2.0 я приведу именно её

Если уж вы хотите ваш пример сделать по MVC то тогда это будет выглядеть так. Есть бар где пользователи наливают себе пивко из бочек, а бармены их только консультируют какие бочки полны а какие нет. Бочка с пивом(в которой есть датчик полноты) - это модель, и она шлёт пуши бармену(наверное тоже надо кибер имплант как приёмник бармену пришить, хотя обычная гарнитура сойдет). Бармен это вид. А краник это контроллер. Тогда похоже на правду

Зависит от размера проекта и его особенностей. Я лично не могу сказать что нашёл идеальную архитектуру и баланс, но мне кажется самое сбалансированное это что-то типа сервис локатора + статической сигнальной шины(статический класс который рассылает ивенты и классы взаимодействуют друг с другом через неё) Я сейчас добью MVVM и попробую запустить новую рубрику: буду писать гиперказуалки и внимание уделять именно архитектуре и паттернам на практике. Пока не знаю что из этого выйдет, как много это займёт времени, но может после публикации того видео моё мнение изменится)

@@sergeykazantsev1655 Ооо, это интересно) Привет от мидкор и гибрид проектов :D

Привет! Ты задал хороший вопрос. Куда нам запихнуть логику передвижения? Согласно концепции MVC логика передвижения должна находиться только в Controller-е. В идеале эта логика передвижения наоборот не должна зависеть от монобеха, а должна полностью считаться на чистом C# без всяких OnCollision/OnTrigger и тд. Так MVC будет чистым, и ты сможешь свою логику передвижения легко перекинуть на какую нибудь джаву или быть готовым к тому что вид или модель у тебя будут написаны на другом языке. На практике конечно никто на чистом MVC никто игры не пишет именно потому что не очень охота ограничивать себя от функционала юнити: физики, коллайдеров и триггеров. Поэтому да, придётся делать контроллер монобехом и счиитать управление там. На счёт "удобно тестить игру, когда напрямую из инспектора можешь менять хп, скорость и тд" - ты можешь создать отдельный класс который объединяет Model, View и Controller и в него прокинуть твои параметры. Тем самым у тебя будет специальный скрипт в котором лежат все с MVC связанное и уже ЭТОТ скрипт ты будешь добавлять в MainScript. Я эту механику ещё не обкатал, хочу во второй игре которую я напишу для рубрики "Паттерны на практике" прикрутить, но мне кажется она зайдет. На счёт MainScript - да, должен быть рутовый какой-то скрипт игры, чаще всего для этого используют паттерн EntryPoint или тот же DI-Container. По Entry Point у меня последнее видео, можно посмотреть как это приблизительно делается. Да, он будет распухать, но всё равно будет трудно построить архитектуру игры без рутового скрипта в котором всё инициализируется. Чистый MVC с моей точки зрения для нас юнитологов подходит не всегда. НО, идея разделять архитектуру так чтобы модель была отдельно, логика отдельно, вид отдельно - очень хорошая и полезная. Есть жанры которые от разделения архитектуры на три слоя(данные логика и вид) сильно выигрывают: те же match3, слот машины или сетевые игры. "когда Is 3 Line Logic == true, работает CentralLineController" - да, поправлю, плохой нейминг, я имел ввиду не Is3Line а Is3SlotOnly

@@sergeykazantsev1655 огромное спасибо

Да, получается так. По крайней мере в каноничном представленном MVC схема именно такая. Контроллер не имеет доступа напрямую к View, контроллер изменяет лишь модель. Опять же уточню, что этой схеме не обязательно следовать, этой схеме много лет и она не совсем адекватно ложится на современный геймдев, но это именно та схема которую представил автор MVC. Да, пожалуйста, можете на меня ссылаться 🙂 Если какие-то ребята захотят подискутировать и поспорить, пусть пишут мне в комментарии, или в личку в тг, вежливую и нетоксичную конструктивную дискуссию я всегда приветствую. И ссылку на линкедин тогда тоже попрошу, я там тоже есть бываю хоть и не часто :)

Хорошее замечание! По моему опыту действительно чистый mvc используется редко, чаще используется MVP или MVVM. Но также в юнити вполне неплохо прижилась идея отделения данных от логики и вида. Писал клоны Coin master-a и для тех же слот машин такой подход заходит на ура :)

Так вот почему, когда я разрабатывал свою первую игру и постоянно вставал вопрос, мол, где главную логику реализовывать в модели или в контроллере.

Как я и сообщал в видео, стрелочки и связи между тремя компонентами вы можете проставить как угодно, в зависимости от потребностей и предпочтений Но канонично модель ссылается на вью. Как я понял эта архитектура была придумана до ивентов, и потому именно модель обновляла вид. Но опять же никто не заставляет следовать ортодоксальной архитектуре равно как и никто не запрещает использовать ивенты

да и метод "Spin" в примере по-идее должен находится в моделе, контроллер может его разве что вызывать

В модели не должно быть когда отвечающего за логику. Логикой занимается контроллер. Если мы один контроллер заменим на другой, что в модели новый метод Spin писать? В модели только сеттеры и ссылка на вид и команда на отрисовку нового состояния модели

@@sergeykazantsev1655 модель по сути чистая бизнес логика, какой смысл переносить её в контроллер? Какой смысл модели знать о наличии вью? Контроллер это внешней класс, который отвечает за связанность модели, вью и юзер-интерфейсов, в то время как модель и вью выполняют свои функции "по приказу" конроллера, но не подозревая о нём, контроллер же следит за моделью либо самостоятельно, либо реагирую на ивенты.

Абсолютно согласен что тот факт, что модель дёргает вью напрямую без контроллера выглядит очень странно. Но так указано в научной работе как Трюгве Реенскауга folk.universitetetioslo.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf (14 страница - две UML диаграммы P11 в правом углу. По ним видно что именно модель шлёт сигнал виду) так и в той же википедии(хотя конечно вики так себе авторитет) ru.wikipedia.org/wiki/Model-View-Controller (model Updates View) В защиту могу сказать что это на этапе становления эту странность в MVP и MVVM пофиксили. В MVP появился Passive View который убирал связь модели и вида, в MVVM вообще все перекрутили на датабиндинг На некоторых статьях по MVC эту проблему так же фиксят как вы рекомендуете, то есть через Controller. Если попробуете загуглить MVC в картинках увидите и тот и другой вариант. Но вариант в видео каноничный, хоть и не значит что строго обязательно следовать ему. Главное чтобы вы решали ваши задачи и вам было удобно И да, ссылку надо прокидывать на него в двух местах, но только наверху в условном MainScript, что не такая уж и проблема

@@sergeykazantsev1655 Слушай, я посмотрел эти диаграммы и я их понимаю так что в контроллере нет ссылки на вью. Контроллер получает команду от пользователя, меняет модель, а модель уже меняет вью. Контроллер со вью вообще никак не связан.

Блин, точняк. А я в коде получается часть логики считаю в контроллере и передаю на вид(логика победы) а часть логики передаю с модели на вид - результат вращения. В общем тогда пример не самый удачный получился :D Надо будет переписать код примера чтобы контроллер не взаимодействовал с вью

@@PinkPanteRus Исправил :D

@@sergeykazantsev1655 Спасибо!

Вот оно как, и правда